Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL

Hi Daniel,

​I 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.
​However, my intention is not to disregard the project's history, but
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.

​Technical Complexity: The ASIO Integration Challenge

​In analyzing the current integration, I see several critical points that
differentiate the current landscape from the debates of ten years ago:

​Impedance Mismatch (ASIO vs. Postgres):

Botan’s TLS architecture often defaults to a data-flow model or relies on
Boost.Asio for event handling. Mapping this to PostgreSQL’s 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.

​Signal 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.

​AI-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—such as abstracting
be-secure-openssl.c into a generic provider interface—can now be executed
with much higher precision and consistent boilerplate generation, allowing
developers to focus on the high-level architectural integrity.

​Why Reopen the Discussion Now?

​My 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 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.

​I have developed a reference model (mentioned in the previous Appendix)
using a proxy to mitigate this coupling, but I believe an internal
abstraction would benefit the core’s long-term resilience.

​Is there a specific design document or thread from previous attempts that
you consider "required reading" so I can avoid repeating past architectural
mistakes in a potential patch proposal?

​Best regards,

El sáb, 21 mar 2026, 21:11, Daniel Gustafsson <daniel(at)yesql(dot)se> escribió:

> > On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <
> fj(dot)gutierrezs91(at)gmail(dot)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
>
>