From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, mikael(dot)kjellstrom(at)gmail(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Date: | 2024-04-15 23:03:41 |
Message-ID: | Zh2yTfwbEPYBaTjp@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 15, 2024 at 11:07:05AM +0200, Daniel Gustafsson wrote:
> On 15 Apr 2024, at 07:04, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-04-15 23:10:44 | Re: Bugs in ecpg's macro mechanism |
Previous Message | Andres Freund | 2024-04-15 22:57:49 | Re: Differential code coverage between 16 and HEAD |