public inbox for [email protected]
help / color / mirror / Atom feedFrom: Javier Gutierrez-Maturana sanchez <[email protected]>
To: [email protected]
Cc: PostgreSQL Hackers <[email protected]>
Cc: Enrique Soriano <[email protected]>
Cc: Gorka Guardiola <[email protected]>
Subject: Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
Date: Sat, 21 Mar 2026 21:47:33 +0100
Message-ID: <CA+5Zhp5sbXuiBm5rEpzxAiZBcHVXo7iqLQwodL1RDyv_5mK2EA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+5Zhp62fb6WMyzm1ZpKiYw3Pbtrjb=Vehug4xKmNeovpNjaCw@mail.gmail.com>
<[email protected]>
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 <[email protected]> escribió:
> > On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <
> [email protected]> 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
>
>
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
In-Reply-To: <CA+5Zhp5sbXuiBm5rEpzxAiZBcHVXo7iqLQwodL1RDyv_5mK2EA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox