Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL - Mailing list pgsql-hackers
| From | Javier Gutierrez-Maturana sanchez |
|---|---|
| Subject | Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL |
| Date | |
| Msg-id | CA+5Zhp5sbXuiBm5rEpzxAiZBcHVXo7iqLQwodL1RDyv_5mK2EA@mail.gmail.com Whole thread Raw |
| In response to | Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL (Daniel Gustafsson <daniel@yesql.se>) |
| List | pgsql-hackers |
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@yesql.se> escribió:
> 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
pgsql-hackers by date: