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

> On 12 Aug 2026, at 11:51, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 09.07.26 23:14, Daniel Gustafsson wrote:
>> The attached implements LibreSSL as a separate TLS library implementation (*)
>> in libpq with fe-secure-libressl.c and be-secure-libressl.c along with build
>> and test infrastructure.
>
> I'm skeptical about this approach. What has been presented so far doesn't convince me that the differences between the openssl and the libressl variants will be larger than their commonalities.

That assumes that future changes are done within the 1.1.1 API, which is
already not the case since 1f3b9bb109b8b1a7b (granted, it's in src/common but
similar patches against be-secure-openssl.c are already on the list).

Personally I'd be much more interested in deprecating 1.1.1 and moving us onto
supported APIs. Until we do there is of course no point in a patch like this
(which I tried to say upthread).

> As an example, my recent patch [0] works just the same on both (AFAICT). I didn't have to worry about the differences at all.

While not introduced in this patch, merely moved, it also use a since 3.0
deprecated API which is not available in LibreSSL. Reading the implementation
they seem quite similar apart from ibreSSL not supporting increased keysize
when using SSL_CTX_set_security_level. While we don't use the security level
API, it's an example of difference behind the API which *I* constantly worry
about when poking at this code.

> 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).

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.

--
Daniel Gustafsson