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

On Wed, Aug 12, 2026 at 08:34:14AM -0700, Jacob Champion wrote:
> 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.

OpenSSL 3.0 has from an architectural point of view forked hard from
LibreSSL. I agree that dropping 1.1.1 and doing this split is a
sensible thing long-term: it would make easier the modernization of
both LibreSSL and OpenSSL code paths.

On top of 1f3b9bb109b8 and b91f79cd08ab, there was a third patch for
channel binding that I was planning to take care of by the end of this
week to be completely done with the EVP switch and the removal of the
legacy SHA APIs for the backend code and libpq. If that's annoying in
terms of what this thread is dealing with, please let me know. I
don't think so, but well, as a wise man said N PostgreSQL hackers can
have up to (N+1) opinions.

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

I say yes to this split in v20, as much as yes to a drop of 1.1.1 in
v20.

My question would be a bit different, though: in which order should
things be worked out? First a file-based split and then a drop of
OpenSSL 1.1.1 or the opposite? I'm finding a drop of OpenSSL 1.1.1
done first a bit unattractive because we still need to support the
LibreSSL path with what OpenSSL has already marked as deprecated.

Please note that I did not look at the internals of LibreSSL to see if
they still recommend the use of the EVP_sha*() routines or not..
--
Michael