public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Postgres hackers <[email protected]>
Cc: [email protected]
Cc: Tom Lane <[email protected]>
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date: Tue, 16 Apr 2024 08:03:41 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Mon, Apr 15, 2024 at 11:07:05AM +0200, Daniel Gustafsson wrote:
> On 15 Apr 2024, at 07:04, Michael Paquier <[email protected]> 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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox