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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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-16 08:17:26
Message-ID: 885D539C-6711-470A-8CD7-44D55E8E5183@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 16 Apr 2024, at 01:03, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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.

I forgot (and didn't check) that we backpatched 01e6f1a842f4, with that in mind
I agree that we should backpatch 0003 as well to put LibreSSL on par as much as
we can. 0004 is a fix for the LibreSSL support, not adding anything new, so
pushing that to master now makes sense. Unless objections are raised I'll push
0001, 0003 and 0004 shortly. 0002 and 0005 can hopefully be addressed in the
July commitfest.

>>> 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?

Meh, I was clearly not caffeinated as that's a thinko with a typo attached to
it. The check should be "< 0x10101000" to catch any version prior to 1.1.1.
Fixed.

--
Daniel Gustafsson

Attachment Content-Type Size
v9-0005-Remove-pg_strong_random-initialization.patch application/octet-stream 4.2 KB
v9-0004-Support-SSL_R_VERSION_TOO_LOW-on-LibreSSL.patch application/octet-stream 1.2 KB
v9-0003-Support-disallowing-SSL-renegotiation-in-LibreSSL.patch application/octet-stream 2.0 KB
v9-0002-Remove-support-for-OpenSSL-1.0.2.patch application/octet-stream 25.8 KB
v9-0001-Doc-Use-past-tense-for-things-which-happened-in-t.patch application/octet-stream 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2024-04-16 08:22:39 Re: promotion related handling in pg_sync_replication_slots()
Previous Message Hayato Kuroda (Fujitsu) 2024-04-16 08:15:33 RE: Disallow changing slot's failover option in transaction block