OpenSSL 3.0.0 vs old branches
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.
Hmm ... according to that commit message,
Note that the minimum supported OpenSSL version is 1.0.1 as of
7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, so this does not introduce
any new version requirements.
So presumably, changing this test would break it for OpenSSL 0.9.8,
which is still nominally supported in those branches. On the other
hand, this test isn't run by default, so users would likely never
notice anyway.
On the whole, +1 for doing this (after the release freeze lifts).
regards, tom lane
On 2023-02-06 Mo 11:13, Tom Lane wrote:
Andrew Dunstan<andrew@dunslane.net> writes:
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.Hmm ... according to that commit message,
Note that the minimum supported OpenSSL version is 1.0.1 as of
7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, so this does not introduce
any new version requirements.So presumably, changing this test would break it for OpenSSL 0.9.8,
which is still nominally supported in those branches. On the other
hand, this test isn't run by default, so users would likely never
notice anyway.On the whole, +1 for doing this (after the release freeze lifts).
Presumably we don't have any buildfarm animals running with such old
versions of openssl, or they would be failing the same test on release
= 13.
I'll push this in due course.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 2023-02-06 Mo 11:13, Tom Lane wrote:
So presumably, changing this test would break it for OpenSSL 0.9.8,
which is still nominally supported in those branches. On the other
hand, this test isn't run by default, so users would likely never
notice anyway.
Presumably we don't have any buildfarm animals running with such old
versions of openssl, or they would be failing the same test on release= 13.
That test isn't run by default in the buildfarm either, no?
But indeed, probably nobody in the community is testing such builds
at all. I did have such setups on my old dinosaur BF animals, but
they bit the dust last year for unrelated reasons. I wonder how
realistic it is to claim that we still support those old OpenSSL
versions.
regards, tom lane
On 06.02.23 16:56, Andrew Dunstan wrote:
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.
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.
On 2023-02-07 Tu 02:18, Peter Eisentraut wrote:
On 06.02.23 16:56, Andrew Dunstan wrote:
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.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.
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 guess the alternatives are a) disable the SSL tests on branches <= 12
or b) completely disable building with SSL for branches <= 12. I would
probably opt for a). I bet this crops up a few more times as OpenSSL
3.0.0 becomes more widespread, until release 12 goes EOL.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.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@eisentraut.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@postgresql.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@postgresql.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@paquier.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
On Tue, Feb 07, 2023 at 01:28:26PM -0500, Tom Lane wrote:
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.
+1. (I am annoyed by that for any backpatch that involves v11 and
v12.)
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).
Cutting support for 0.9.8 in oldest branches would be a very risky
move, but as you say, if that only involves a failure in the SSL
tests while still allowing anything we have to work, fine by me to
live with that.
Saying that, not being able to test these when working on a
SSL-specific patch adds an extra cost in back-patching. There are not
many of these lately, so that may be OK, still it would mean to apply
a reverse of f0d2c65. If things were to work for all the versions of
OpenSSL supported on 11 and 12, would it mean that the tests need to
store both -des and -aes256 data, having the tests switch from one to
the other depending on the version of OpenSSL built with?
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Tue, Feb 07, 2023 at 01:28:26PM -0500, Tom Lane wrote:
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).
Cutting support for 0.9.8 in oldest branches would be a very risky
move, but as you say, if that only involves a failure in the SSL
tests while still allowing anything we have to work, fine by me to
live with that.
Question: is anybody around here still testing with 0.9.8 (or 1.0.x)
at all? The systems I had that had that version on them are dead.
regards, tom lane
On 2023-02-07 Tu 23:37, Tom Lane wrote:
Michael Paquier<michael@paquier.xyz> writes:
On Tue, Feb 07, 2023 at 01:28:26PM -0500, Tom Lane wrote:
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).Cutting support for 0.9.8 in oldest branches would be a very risky
move, but as you say, if that only involves a failure in the SSL
tests while still allowing anything we have to work, fine by me to
live with that.Question: is anybody around here still testing with 0.9.8 (or 1.0.x)
at all? The systems I had that had that version on them are dead.
In the last 30 days, only the following buildfarm animals have reported
running the ssl checks on the relevant branches:
crake
eelpout
fairywren
gokiburi
hachi
longfin
I don't think any of these runs openssl <= 1.0.x. If we want to preserve
testability for those very old versions we should actually be doing some
testing. Or we could just move on and backpatch this as I've suggested.
I'll be pretty surprised if we get a single complaint.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Op 08-02-2023 om 05:37 schreef Tom Lane:
Michael Paquier <michael@paquier.xyz> writes:
On Tue, Feb 07, 2023 at 01:28:26PM -0500, Tom Lane wrote:
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).Cutting support for 0.9.8 in oldest branches would be a very risky
move, but as you say, if that only involves a failure in the SSL
tests while still allowing anything we have to work, fine by me to
live with that.Question: is anybody around here still testing with 0.9.8 (or 1.0.x)
at all? The systems I had that had that version on them are dead.regards, tom lane
I've hoarded an old centos 6.1 system that I don't really use anymore
but sometimes (once every few weeks, I guess) start up and build master
on, for instance to test with postgres_fdw/replication. Such a build
would include a make check, and I think I would have noticed any fails.
That system says:
OpenSSL> OpenSSL 1.0.1e-fips 11 Feb 2013
FWIW, just now I built & ran check-world for 15 and 16 with
PG_TEST_EXTRA=ssl (which I didn't use before). Both finished ok.
Erik Rijkers
On 07.02.23 19:28, Tom Lane wrote:
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.
Ok, let's do it.
Erik Rijkers <er@xs4all.nl> writes:
Op 08-02-2023 om 05:37 schreef Tom Lane:
Question: is anybody around here still testing with 0.9.8 (or 1.0.x)
at all? The systems I had that had that version on them are dead.
I've hoarded an old centos 6.1 system that I don't really use anymore
but sometimes (once every few weeks, I guess) start up and build master
on, for instance to test with postgres_fdw/replication. Such a build
would include a make check, and I think I would have noticed any fails.
That system says:
OpenSSL> OpenSSL 1.0.1e-fips 11 Feb 2013
FWIW, just now I built & ran check-world for 15 and 16 with
PG_TEST_EXTRA=ssl (which I didn't use before). Both finished ok.
Oh, that's good to know. That means that the newer form of this
test works with 1.0.1, which means that we'd only lose test
compatibility with 0.9.x OpenSSL. That bothers me not at all
in 2023.
regards, tom lane
On 2023-02-08 We 10:42, Peter Eisentraut wrote:
On 07.02.23 19:28, Tom Lane wrote:
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.Ok, let's do it.
Done
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On Wed, Feb 08, 2023 at 07:30:32AM -0500, Andrew Dunstan wrote:
In the last 30 days, only the following buildfarm animals have reported
running the ssl checks on the relevant branches:gokiburi
hachi
FWIW, these two ones are using OpenSSL 1.1.1, so that's fine.
--
Michael