public inbox for [email protected]
help / color / mirror / Atom feedProposal: Implementing Botan as an alternative TLS backend for PostgreSQL
4+ messages / 3 participants
[nested] [flat]
* Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
@ 2026-03-21 18:44 Javier Gutierrez-Maturana sanchez <[email protected]>
2026-03-21 20:11 ` Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Daniel Gustafsson <[email protected]>
2026-03-22 10:53 ` Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Enrique Soriano <[email protected]>
0 siblings, 2 replies; 4+ messages in thread
From: Javier Gutierrez-Maturana sanchez @ 2026-03-21 18:44 UTC (permalink / raw)
To: [email protected]; Enrique Soriano <[email protected]>; Gorka Guardiola <[email protected]>
Hello PostgreSQL community,
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).
While OpenSSL is the current standard, the "rules of the game" in software
engineering are changing. The advent of advanced AI-assisted development
tools now provides the technical viability to undertake significant
refactorings—such as abstracting the network security layer—with much
higher precision and lower overhead than in the past.
The primary motivation for adding Botan support is **compliance and
architectural flexibility**:
1. **Regulatory Requirements:** In jurisdictions like Spain, the **CCN
(Centro Criptológico Nacional)** sets specific standards for cryptographic
modules. Having an alternative like Botan facilitates certification in
these restricted environments.
2. **Architectural Robustness:** A provider-agnostic TLS layer makes
PostgreSQL more resilient to library-specific vulnerabilities or licensing
changes.
3. **Modern Integration:** Using Botan's C wrappers allows the engine to
benefit from a modern C++ cryptographic core while maintaining the
project's C-based architecture.
I am interested in knowing the community's stance on abstracting
`be-secure-openssl.c` into a more generic interface.
Best regards,
[Tu Nombre]
---
### Appendix: Proof of Concept - Proxy Model with Botan
To validate the viability of Botan in high-security environments without
depending on OpenSSL's native integration, I have developed a reference
implementation available at:
👉 [
https://github.com/jgmatu/management-sensors](https://github.com/jgmatu/management-sensors)
**Architectural Model:**
In this project, I implemented a **Quantum-Safe Proxy** that acts as a
bridge between non-PQC clients and the core system. Key features of this
model include:
* **Decoupled TLS Engine:** Using `QuantumSafeTlsEngine` (based on Botan
TLS v1.3) to handle all secure handshakes independently of the application
logic.
* **Reactive Event Bus:** Utilizing PostgreSQL's `LISTEN/NOTIFY` mechanism
to manage state and configurations without direct coupling between the
server and the controllers.
* **Post-Quantum Ready:** Demonstrating that Botan can provide PQC
(Post-Quantum Cryptography) algorithms today, which is a requirement
increasingly demanded by national security agencies like the CCN.
This proxy model proves that Botan is not only a viable alternative but
also provides advanced features that are currently difficult to implement
with a hard dependency on OpenSSL.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
2026-03-21 18:44 Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]>
@ 2026-03-21 20:11 ` Daniel Gustafsson <[email protected]>
2026-03-21 20:47 ` Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]>
1 sibling, 1 reply; 4+ messages in thread
From: Daniel Gustafsson @ 2026-03-21 20:11 UTC (permalink / raw)
To: Javier Gutierrez-Maturana sanchez <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Enrique Soriano <[email protected]>; Gorka Guardiola <[email protected]>
> 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
2026-03-21 18:44 Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]>
2026-03-21 20:11 ` Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Daniel Gustafsson <[email protected]>
@ 2026-03-21 20:47 ` Javier Gutierrez-Maturana sanchez <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Javier Gutierrez-Maturana sanchez @ 2026-03-21 20:47 UTC (permalink / raw)
To: [email protected]; +Cc: PostgreSQL Hackers <[email protected]>; Enrique Soriano <[email protected]>; Gorka Guardiola <[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
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
2026-03-21 18:44 Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]>
@ 2026-03-22 10:53 ` Enrique Soriano <[email protected]>
1 sibling, 0 replies; 4+ messages in thread
From: Enrique Soriano @ 2026-03-22 10:53 UTC (permalink / raw)
To: Javier Gutierrez-Maturana sanchez <[email protected]>; +Cc: [email protected]; Gorka Guardiola <[email protected]>
I’m not quite sure why I was included in this thread, I am not interested
in this topic. Kindly remove me from any future emails.
Regards,
Enrique
On Sat, 21 Mar 2026 at 19:44, Javier Gutierrez-Maturana sanchez <
[email protected]> wrote:
>
>
> Hello PostgreSQL community,
>
> 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).
>
> While OpenSSL is the current standard, the "rules of the game" in software
> engineering are changing. The advent of advanced AI-assisted development
> tools now provides the technical viability to undertake significant
> refactorings—such as abstracting the network security layer—with much
> higher precision and lower overhead than in the past.
>
> The primary motivation for adding Botan support is **compliance and
> architectural flexibility**:
>
> 1. **Regulatory Requirements:** In jurisdictions like Spain, the **CCN
> (Centro Criptológico Nacional)** sets specific standards for cryptographic
> modules. Having an alternative like Botan facilitates certification in
> these restricted environments.
> 2. **Architectural Robustness:** A provider-agnostic TLS layer makes
> PostgreSQL more resilient to library-specific vulnerabilities or licensing
> changes.
> 3. **Modern Integration:** Using Botan's C wrappers allows the engine to
> benefit from a modern C++ cryptographic core while maintaining the
> project's C-based architecture.
>
> I am interested in knowing the community's stance on abstracting
> `be-secure-openssl.c` into a more generic interface.
>
> Best regards,
>
> [Tu Nombre]
>
> ---
>
> ### Appendix: Proof of Concept - Proxy Model with Botan
>
> To validate the viability of Botan in high-security environments without
> depending on OpenSSL's native integration, I have developed a reference
> implementation available at:
> 👉 [
> https://github.com/jgmatu/management-sensors](https://github.com/jgmatu/management-sensors)
>
> **Architectural Model:**
> In this project, I implemented a **Quantum-Safe Proxy** that acts as a
> bridge between non-PQC clients and the core system. Key features of this
> model include:
>
> * **Decoupled TLS Engine:** Using `QuantumSafeTlsEngine` (based on Botan
> TLS v1.3) to handle all secure handshakes independently of the application
> logic.
> * **Reactive Event Bus:** Utilizing PostgreSQL's `LISTEN/NOTIFY` mechanism
> to manage state and configurations without direct coupling between the
> server and the controllers.
> * **Post-Quantum Ready:** Demonstrating that Botan can provide PQC
> (Post-Quantum Cryptography) algorithms today, which is a requirement
> increasingly demanded by national security agencies like the CCN.
>
> This proxy model proves that Botan is not only a viable alternative but
> also provides advanced features that are currently difficult to implement
> with a hard dependency on OpenSSL.
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-03-22 10:53 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-21 18:44 Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]>
2026-03-21 20:11 ` Daniel Gustafsson <[email protected]>
2026-03-21 20:47 ` Javier Gutierrez-Maturana sanchez <[email protected]>
2026-03-22 10:53 ` Enrique Soriano <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox