Re: LibreSSL and OpenSSL separation in libpq to support 1.1.1 deprecation

On Wed, Aug 12, 2026 at 8:14 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > Under the proposed system, I would have to make the same code changes twice, test everything twice (including obtaining libressl in the first place and set up a separate build for it). Doesn't sound appealing.
>
> Testing everything twice isn't new, we already need to test all libpq TLS
> related changes on both OpenSSL and LibreSSL since they are supported.
> Trusting that one works because the other one does is a brittle assumption and
> I've had to revert commits because of precisely that reason. Applying code
> twice is a real pain though, but navigating an increased level of ifdefs won't
> be pleasant either (assuming it happens of course).

+1 -- this is where I kind of raised an eyebrow at your argument,
Peter. We're already doing that, and we *must* do it, whether it's
obvious or not that said work is being done. I'm very much in favor of
splitting that apart and making the invisible pain visible (at least
conceptually -- I haven't had a chance yet to sit down and look at
this particular patch, and I'm very sorry for that; maybe a hybrid
such as Alvaro's suggestion would work too).

In my opinion, keeping the two same-in-name-but-not-in-practice
implementations together is keeping things more brittle, not less,
most recently when I look at the SNI work. If we split the two, then
in addition to not risking 1.1.1-based destabilization as we move to
4.0 APIs, we can investigate porting LibreSSL code on top of their
libtls API instead.

> Again, all of this is moot if we don't deprecate 1.1.1 support, but I don't
> think we are doing our users a service by allowing them to use an TLS library
> which when v20 goes EOL has been out of security updates for 8+ years.

We should do that for PG20. I'm continuing to push for that in other
threads [1]. No one has said "no" yet, I think, so IMNSHO we should
just do it.

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2B%3DVJJ%3D1a-wHwWd2mTgQ3bkHzAUHCFssosF7h1y8TEN%2Biw%40mail.gmail.com