On Mon, Apr 15, 2024 at 11:07:05AM +0200, Daniel Gustafsson wrote: > On 15 Apr 2024, at 07:04, Michael Paquier <mich...@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
signature.asc
Description: PGP signature