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

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Дата
Msg-id 885D539C-6711-470A-8CD7-44D55E8E5183@yesql.se
обсуждение исходный текст
Ответ на Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Список pgsql-hackers

> On 16 Apr 2024, at 01:03, Michael Paquier <michael@paquier.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@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.

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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: Disallow changing slot's failover option in transaction block
Следующее
От: shveta malik
Дата:
Сообщение: Re: promotion related handling in pg_sync_replication_slots()