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

> On 6 Apr 2024, at 16:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 6 Apr 2024, at 08:02, Peter Eisentraut <peter@eisentraut.org> wrote:

>>> Why do we need to check for the versions at all?  We should just check for the functions we need.  At least that's always been the normal approach in configure.
> 
>> We could, but finding a stable set of functions which identifies the version of
>> OpenSSL *and* LibreSSL that we want, and their successors, while not matching
>> any older versions seemed more opaque than testing two numeric values.
> 
> I don't think you responded to Peter's point at all.  The way autoconf
> is designed to work is explicitly NOT to try to identify the exact
> version of $whatever.  Rather, the idea is to probe for the API
> features that you want to rely on: functions, macros, struct fields,
> or the like.  If you can't point to an important API difference
> between 1.0.2 and 1.1.1, why drop support for 1.0.2?

My apologies, I thought I did but clearly failed.  My point was that this is a
special/corner case where we try to find one of two different libraries (with
different ideas about backwards compatability etc) for supporting a single
thing.  So instead I tested for the explicit versions like how we already test
for the exact Perl version in config/perl.m4 (albeit that a library and a
program are two different things of course).

In bumping we want to move to 1.1.1 since that's the first version with the
rewritten RNG which is fork-safe by design, something PostgreSQL clearly
benefits from.  There is no new API for this to gate on though.  For LibreSSL
we want 3.3.2 to a) ensure we have coverage in the BF and b) since it's the
first version where the tests pass due to error message alignment with OpenSSL.
The combination of these gets rid of lots of specialcased #ifdef soup.  I
wasn't however able to find a specific API call which is unique to the two
version which we rely on.

Testing for the presence of an API provided and introduced by both libraries in
the version we're interested in, but which we don't use, is the alternative but
I thought that would be more frowned upon.  EVP_PKEY_new_CMAC_key() was
introduced in 1.1.1 and LibreSSL 3.3.2, so an AC_CHECK_FUNCS for that, as in
the attached, achieves the version check but pollutes pg_config.h with a define
which will never be used which seemed a bit ugly.

--
Daniel Gustafsson