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

On Mon, Apr 15, 2024 at 11:07:05AM +0200, Daniel Gustafsson wrote:
> On 15 Apr 2024, at 07:04, Michael Paquier <michael@paquier.xyz> wrote:
>> On Fri, Apr 12, 2024 at 02:42:57PM +0200, Daniel Gustafsson wrote:
>>> Is the attached split in line with how you were thinking about it?
>> 
>> If I may, 0001 looks sensible here.  The bits from 0003 and 0004 could
>> be applied before 0002, as well.
> 
> Agreed, once we are in post-freeze I think those three are mostly
> ready to go.

Is there a point to wait for 0001, 0003 and 0004, though, and
shouldn't these three be backpatched?  0001 is certainly OK as a
doc-only change to be consistent across the board without waiting 5
more years.  0003 and 0004 are conditional and depend on if
SSL_R_VERSION_TOO_LOW and SSL_OP_NO_CLIENT_RENEGOTIATION are defined
at compile-time.  0003 is much more important, and note that
01e6f1a842f4 has been backpatched all the way down.  0004 is nice,
still not strongly mandatory.

>> Rather than calling always RAND_poll(), this
>> could use a static flag to call it only once when pg_strong_random is
>> called for the first time.
> 
> Agreed, we can good that. Fixed.

+#if (OPENSSL_VERSION_NUMBER <= 0x10100000L)
+	static bool rand_initialized = false;

This does not look right.  At the top of upstream's branch
OpenSSL_1_1_0-stable, OPENSSL_VERSION_NUMBER is 0x101000d0L, so the
initialization would be missed for any version in the 1.1.0 series
except the GA one without this code being compiled, no?

>> I would not mind seeing this part entirely
>> gone with the removal of support for 1.1.0.
> 
> If we want to keep autoconf from checking versions and just check compatibility
> (with our code) then we will remain at 1.1.0 compatibility.  The only 1.1.1 API
> we use is not present in LibreSSL so we can't really place a hard restriction
> on that.  It might be that keeping it for now, and removing it later during the
> v18 cycle as we modernize our OpenSSL code (which I hope to find time to work
> on) and make use of newer 1.1.1 API:s.  That way we can keep our autoconf/meson
> checks consistent across library checks.  If we end up with no new API:s to
> check for by the time the last commitfest of v18 rolls around, we can revisit
> the decision then.

Okay, fine by me.
--
Michael