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