> On 12 Aug 2026, at 11:51, Peter Eisentraut <[email protected]> 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
