MIME-Version: 1.0
References: 
 <CA+5Zhp62fb6WMyzm1ZpKiYw3Pbtrjb=Vehug4xKmNeovpNjaCw@mail.gmail.com>
 <9C26F7E9-80F4-400C-B5F4-A32992ABDBE0@yesql.se>
In-Reply-To: <9C26F7E9-80F4-400C-B5F4-A32992ABDBE0@yesql.se>
From: Javier Gutierrez-Maturana sanchez <fj.gutierrezs91@gmail.com>
Date: Sat, 21 Mar 2026 21:47:33 +0100
Message-ID: 
 <CA+5Zhp5sbXuiBm5rEpzxAiZBcHVXo7iqLQwodL1RDyv_5mK2EA@mail.gmail.com>
Subject: Re: Proposal: Implementing Botan as an alternative TLS backend for
 PostgreSQL
To: daniel@yesql.se
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Enrique Soriano <enrique.soriano@gmail.com>,
 Gorka Guardiola <paurea@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d83d9b064d8ee970"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2B5Zhp5sbXuiBm5rEpzxAiZBcHVXo7iqLQwodL1RDyv_5mK2EA%40mail.gmail.com>
Precedence: bulk

--000000000000d83d9b064d8ee970
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

=E2=80=8BI appreciate the pointer. You are correct that the abstraction of =
the SSL
layer is a topic that has surfaced on the mailing list multiple times over
the last decade.
=E2=80=8BHowever, my intention is not to disregard the project's history, b=
ut
rather to re-evaluate the technical viability under current architectural
conditions. One of the primary historical hurdles for integrating modern
libraries like Botan into a C-based project like PostgreSQL has been
Botan's reliance on Boost.Asio or C++-centric asynchronous I/O models for
communications management.


=E2=80=8BTechnical Complexity: The ASIO Integration Challenge


=E2=80=8BIn analyzing the current integration, I see several critical point=
s that
differentiate the current landscape from the debates of ten years ago:

=E2=80=8BImpedance Mismatch (ASIO vs. Postgres):

Botan=E2=80=99s TLS architecture often defaults to a data-flow model or rel=
ies on
Boost.Asio for event handling. Mapping this to PostgreSQL=E2=80=99s process=
-based,
synchronous socket model introduces significant complexity. Bridging a
C++-heavy asynchronous event loop into a legacy C codebase without
introducing "callback hell" is a non-trivial engineering task.


=E2=80=8BSignal and Memory Management:

Integrating a C++ runtime requires careful handling of PostgreSQL's custom
memory management (palloc) and signal handling (Longjmp-based error
recovery), which can conflict with C++ exception handling and ASIO's
internal state.


=E2=80=8BAI-Assisted Refactoring: A key differentiator today is the advent =
of
Advanced AI Agents.

These tools significantly lower the overhead of large-scale refactorings.
Tasks that were previously deemed too labor-intensive=E2=80=94such as abstr=
acting
be-secure-openssl.c into a generic provider interface=E2=80=94can now be ex=
ecuted
with much higher precision and consistent boilerplate generation, allowing
developers to focus on the high-level architectural integrity.

=E2=80=8BWhy Reopen the Discussion Now?

=E2=80=8BMy proposal stems from the need to comply with security agency reg=
ulations
(such as the CCN in Spain), which are beginning to mandate cryptographic
agility and Post-Quantum Cryptography (PQC) readiness. Botan offers a
native path toward PQC that is currently more complex to maintain solely
through OpenSSL patches or oqs providers.

=E2=80=8BI have developed a reference model (mentioned in the previous Appe=
ndix)
using a proxy to mitigate this coupling, but I believe an internal
abstraction would benefit the core=E2=80=99s long-term resilience.

=E2=80=8BIs there a specific design document or thread from previous attemp=
ts that
you consider "required reading" so I can avoid repeating past architectural
mistakes in a potential patch proposal?

=E2=80=8BBest regards,

El s=C3=A1b, 21 mar 2026, 21:11, Daniel Gustafsson <daniel@yesql.se> escrib=
i=C3=B3:

> > On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <
> fj.gutierrezs91@gmail.com> wrote:
>
> > I would like to start a discussion regarding the feasibility of
> decoupling our current TLS implementation to allow for alternative
> cryptographic backends, specifically **Botan** (via its C wrapper).
>
> You should perhaps start by doing basic level research, since we did that
> over
> a decade ago.
>
> --
> Daniel Gustafsson
>
>

--000000000000d83d9b064d8ee970
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Hi Daniel,</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">=E2=80=8BI appreciate the pointer. You are correct t=
hat the abstraction of the SSL layer is a topic that has surfaced on the ma=
iling list multiple times over the last decade.</div><div dir=3D"auto">=E2=
=80=8BHowever, my intention is not to disregard the project&#39;s history, =
but rather to re-evaluate the technical viability under current architectur=
al conditions. One of the primary historical hurdles for integrating modern=
 libraries like Botan into a C-based project like PostgreSQL has been Botan=
&#39;s reliance on Boost.Asio or C++-centric asynchronous I/O models for co=
mmunications management.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">=E2=80=8BTechnical Complexity: The ASIO Integr=
ation Challenge</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">=E2=80=8BIn analyzing the current integration, I see se=
veral critical points that differentiate the current landscape from the deb=
ates of ten years ago:</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
=E2=80=8BImpedance Mismatch (ASIO vs. Postgres):</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Botan=E2=80=99s TLS architecture often defaults to=
 a data-flow model or relies on Boost.Asio for event handling. Mapping this=
 to PostgreSQL=E2=80=99s process-based, synchronous socket model introduces=
 significant complexity. Bridging a C++-heavy asynchronous event loop into =
a legacy C codebase without introducing &quot;callback hell&quot; is a non-=
trivial engineering task.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">=E2=80=8BSignal and Memory Management:</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Integrating a C++ runtime requ=
ires careful handling of PostgreSQL&#39;s custom memory management (palloc)=
 and signal handling (Longjmp-based error recovery), which can conflict wit=
h C++ exception handling and ASIO&#39;s internal state.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=8BAI-Ass=
isted Refactoring: A key differentiator today is the advent of Advanced AI =
Agents.</div><div dir=3D"auto"><br></div><div dir=3D"auto">These tools sign=
ificantly lower the overhead of large-scale refactorings. Tasks that were p=
reviously deemed too labor-intensive=E2=80=94such as abstracting be-secure-=
openssl.c into a generic provider interface=E2=80=94can now be executed wit=
h much higher precision and consistent boilerplate generation, allowing dev=
elopers to focus on the high-level architectural integrity.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">=E2=80=8BWhy Reopen the Discussion No=
w?</div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=8BMy proposal =
stems from the need to comply with security agency regulations (such as the=
 CCN in Spain), which are beginning to mandate cryptographic agility and Po=
st-Quantum Cryptography (PQC) readiness. Botan offers a native path toward =
PQC that is currently more complex to maintain solely through OpenSSL patch=
es or oqs providers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=
=80=8BI have developed a reference model (mentioned in the previous Appendi=
x) using a proxy to mitigate this coupling, but I believe an internal abstr=
action would benefit the core=E2=80=99s long-term resilience.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">=E2=80=8BIs there a specific design d=
ocument or thread from previous attempts that you consider &quot;required r=
eading&quot; so I can avoid repeating past architectural mistakes in a pote=
ntial patch proposal?</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
=E2=80=8BBest regards,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">El s=C3=A1b, 21 mar 2026, 21:11, Daniel Gustafsson &l=
t;<a href=3D"mailto:daniel@yesql.se" target=3D"_blank" rel=3D"noreferrer">d=
aniel@yesql.se</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">&gt; On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez &lt;<a =
href=3D"mailto:fj.gutierrezs91@gmail.com" rel=3D"noreferrer noreferrer" tar=
get=3D"_blank">fj.gutierrezs91@gmail.com</a>&gt; wrote:<br>
<br>
&gt; I would like to start a discussion regarding the feasibility of decoup=
ling our current TLS implementation to allow for alternative cryptographic =
backends, specifically **Botan** (via its C wrapper).<br>
<br>
You should perhaps start by doing basic level research, since we did that o=
ver<br>
a decade ago.<br>
<br>
--<br>
Daniel Gustafsson<br>
<br>
</blockquote></div></div>

--000000000000d83d9b064d8ee970--