Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date
Msg-id ZhcWDNySgOJCTyxY@paquier.xyz
Whole thread Raw
In response to Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Wed, Apr 10, 2024 at 09:31:16AM +0200, Peter Eisentraut wrote:
> I think it might be better to separate this into two steps:
>
> 1. Move to 1.1.0.  This is an API update.  Change OPENSSL_API_COMPAT, and
> remove a bunch of code that no longer needs to be conditional.  We could
> check for a representative function like OPENSSL_init_ssl() in
> configure/meson, or we could just let the compilation fail with older
> versions.
>
> 2. Move to 1.1.1.  I understand this has to do with the fork-safety of
> pg_strong_random(), and it's not an API change but a behavior change. Let's
> make this association clearer in the code.  For example, add a version check
> or assertion about this into pg_strong_random() itself.

+1 for a split and a two-step move.  The areas cleaned up are not
really dependent.

> I don't know how LibreSSL interacts with either of these two points. That's
> something that could be clearer.

Not looked at that, unfortunately.  Cutting to one specific version of
LibreSSL would help.

> I would prefer to remove pg_strong_random_init() if it's no longer useful.
> I mean, if we leave it as is, and we are not removing any callers, then we
> are effectively continuing to support OpenSSL <1.1.1, right?

I'd rather see it gone too, at the end, but I also get that the
concerns from Daniel are worth keeping in mind.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Improve eviction algorithm in ReorderBuffer
Next
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed