Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 30 Mar 2024, at 22:27, Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sun, Mar 31, 2024 at 9:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thanks a lot for bringing this up again Thomas, 1.0.2 has bitten me so many
times and I'd be thrilled to get rid of it.

>> I think it's probably true that <=1.0.2 is not in any distro that
>> we still need to pay attention to, but I reject the contention
>> that RHEL8 is not in that set.
> 
> Hmm, OK so it doesn't have 3 available in parallel from base repos.
> But it's also about to reach end of "full support" in 2 months[1], so
> if we applied the policies we discussed in the LLVM-vacuuming thread
> (to wit: build farm - EOL'd OSes), then...  One question I'm unclear
> on is whether v17 will be packaged for RHEL8.

While 1.1.1 is EOL in upstream, it won't buy us much to deprecate past it since
we don't really make use of 3.x specific functionality.  I wouldn't mind not
being on the hook to support an EOL version of OpenSSL for another 5 years, but
it also won't shift the needle too much.  For v18 I'd like to work on modernize
our OpenSSL code to make more use of 3+ features/API's and that could be a good
point to cull 1.1.1 support.

Settling for removing support for 1.0.2, which is antiques roadshow material at
this point (no TLSv1.3 support for example), removes most of the compatibility
mess we have in libpq.  1.1.1 was not a deprecation point in OpenSSL but we can
define 1.1.0 as our compatibility level to build warning-free.

The attached removes 1.0.2 support (meson build parts untested yet) with a few
small touch ups of related documentation.  I haven't yet done the research on
where that leaves LibreSSL since we don't really define anywhere what we
support (so for we've gotten by assuming it's kind of sort 1.0.2 for the parts
we care about which is skating on fairly thin ice).

--
Daniel Gustafsson