Re: OpenSSL 3.0.0 vs old branches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 vs old branches
Date: 2023-02-07 18:28:26
Message-ID: 3211706.1675794506@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2023-02-07 Tu 02:18, Peter Eisentraut wrote:
>> This is not the only patch that we did to support OpenSSL 3.0.0. There
>> was a very lengthy discussion that resulted in various patches. 
>> Unless we have a complete analysis of what was done and how it affects
>> various branches, I would not do this.  Notably, we did actually
>> consider what to backpatch, and the current state is the result of
>> that.  So let's not throw that away without considering that
>> carefully.  Even if it gets it to compile, I personally would not
>> *trust* it without that analysis.  I think we should just leave it
>> alone and consider OpenSSL 3.0.0 unsupported in the branches were it
>> is now unsupported.  OpenSSL 1.1.1 is still supported upstream to
>> serve those releases.

AFAICT we did back-patch those changes into the branches at issue.
I find this in the 12.9 and 11.14 release notes, for example:

<listitem>
<!--
Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
Branch: master Release: REL_14_BR [22e1943f1] 2021-03-23 11:48:37 +0100
Branch: REL_13_STABLE [a69e1506f] 2021-09-25 11:25:48 +0200
Branch: REL_12_STABLE [90cfd269f] 2021-09-25 11:25:48 +0200
Branch: REL_11_STABLE [0f28d267c] 2021-09-25 11:25:48 +0200
Branch: REL_10_STABLE [841075a65] 2021-09-25 11:25:48 +0200
Author: Daniel Gustafsson <dgustafsson(at)postgresql(dot)org>
Branch: master [318df8023] 2021-08-10 15:01:52 +0200
Branch: REL_14_STABLE Release: REL_14_0 [4fa2b15e1] 2021-09-25 11:27:20 +0200
Branch: REL_13_STABLE [135d8687a] 2021-09-25 11:27:20 +0200
Branch: REL_12_STABLE [00c72da4a] 2021-09-25 11:27:20 +0200
Branch: REL_11_STABLE [11901cd96] 2021-09-25 11:27:20 +0200
Branch: REL_10_STABLE [e802b594e] 2021-09-25 11:27:20 +0200
Author: Daniel Gustafsson <dgustafsson(at)postgresql(dot)org>
Branch: master [72bbff4cd] 2021-08-10 15:08:46 +0200
Branch: REL_14_STABLE Release: REL_14_0 [6d0001aab] 2021-09-25 11:27:28 +0200
Branch: REL_13_STABLE [8e7199453] 2021-09-25 11:27:28 +0200
Branch: REL_12_STABLE [7b6ce36fb] 2021-09-25 11:27:28 +0200
Branch: REL_11_STABLE [19e91a40b] 2021-09-25 11:27:28 +0200
Branch: REL_10_STABLE [eb643536b] 2021-09-25 11:27:28 +0200
Author: Michael Paquier <michael(at)paquier(dot)xyz>
Branch: master [41f30ecc2] 2021-10-20 16:48:24 +0900
Branch: REL_14_STABLE [81aefaea8] 2021-10-20 16:48:57 +0900
Branch: REL_13_STABLE [abb9ee92c] 2021-10-20 16:49:00 +0900
Branch: REL_12_STABLE [1539e0ecd] 2021-10-20 16:49:03 +0900
Branch: REL_11_STABLE [e00d45fea] 2021-10-20 16:49:06 +0900
Branch: REL_10_STABLE [922e3c3b7] 2021-10-20 16:49:10 +0900
Branch: REL9_6_STABLE [d581960df] 2021-10-20 16:49:14 +0900
-->
<para>
Support OpenSSL 3.0.0
(Peter Eisentraut, Daniel Gustafsson, Michael Paquier)
</para>
</listitem>

> The only thing this commit does is replace a DES encrypted key file with
> one encrypted with AES-256. It doesn't affect compilation at all, and
> shouldn't affect tests run with 1.1.1.

I double-checked this on Fedora 37 (openssl 3.0.5). v11 and v12
do build --with-openssl. There are an annoyingly large number of
-Wdeprecated-declarations warnings, but those are there in v13 too.
I confirm that back-patching f0d2c65f17 is required and sufficient
to make the ssl test pass.

I think Peter's misremembering the history, and OpenSSL 3 *is*
supported in these branches. There could be an argument for
not back-patching f0d2c65f17 on the grounds that pre-1.1.1 is
also supported there. On the whole though, it seems more useful
today for that test to pass with 3.x than for it to pass with 0.9.8.
And I can't see investing effort to make it do both (but if Peter
wants to, I won't stand in the way).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-02-07 19:48:22 possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Previous Message Andres Freund 2023-02-07 18:27:25 Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent