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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date: 2023-05-27 02:02:41
Message-ID: ZHFkwZKYcgq0zk37@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 26, 2023 at 09:10:17AM -0700, Jacob Champion wrote:
> Can X509_get_signature_nid be moved to the required section up above?
> As it is now, anyone configuring with -Dssl=auto can still pick up a
> 1.0.1 build, which Meson accepts, and then the build fails downstream.
> If we require the function instead, Meson will ignore 1.0.1 (or, for
> -Dssl=openssl, complain before we compile).

Yes, I was wondering a bit if something more should be marked as
required, but just saw more value in removing all references to this
function. Making the build fail straight when setting up things is OK
by me, but I am not convinced that X509_get_signature_nid() would be
the right choice for the job, as it is an OpenSSL artifact originally,
AFAIK.

The same problem exists with OpenSSL 1.0.0 on HEAD when building with
meson? CRYPTO_new_ex_data() and SSL_new() exist there.

> t/001_ssltests.pl has a reference to 1.0.1 that can probably be
> entirely deleted:
>
> # ... (Nor for OpenSSL
> # 1.0.1, but that's old enough that accommodating it isn't worth the cost.)

Not touching that is intentional. It sounded useful to me as an
historic reference for LibreSSL ;)
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-05-27 12:01:58 Re: Implement generalized sub routine find_in_log for tap test
Previous Message vignesh C 2023-05-27 00:35:24 Re: Implement generalized sub routine find_in_log for tap test