Thread: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0
Remove support for OpenSSL 0.9.8 and 1.0.0 Support is out of scope from all the major vendors for these versions (for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1), and it created some extra maintenance work. Upstream has stopped support of 0.9.8 in December 2015 and of 1.0.0 in February 2016. Since b1abfec, note that the default SSL protocol version set with ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL 1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1 in the SSL tests. Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a Modified Files -------------- doc/src/sgml/installation.sgml | 2 +- doc/src/sgml/libpq.sgml | 4 ---- src/backend/libpq/be-secure-openssl.c | 2 -- src/interfaces/libpq/fe-secure-openssl.c | 5 +---- src/test/ssl/t/SSLServer.pm | 4 ---- 5 files changed, 2 insertions(+), 15 deletions(-)
On Mon, Jan 06, 2020 at 03:53:08AM +0000, Michael Paquier wrote: > Remove support for OpenSSL 0.9.8 and 1.0.0 > > Support is out of scope from all the major vendors for these versions > (for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1), > and it created some extra maintenance work. Upstream has stopped > support of 0.9.8 in December 2015 and of 1.0.0 in February 2016. > > Since b1abfec, note that the default SSL protocol version set with > ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL > 1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1 > in the SSL tests. So the buildfarm is not that bad, I have spotted one failure from nightjar: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2020-01-06%2003%3A54%3A10 /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c: In function 'initialize_SSL': /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: error: 'SSL_OP_NO_COMPRESSION' undeclared (first use in this function) /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: error: (Each undeclared identifier is reported only once /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: error: for each function it appears in.) And this means that the version likely used here should be 0.9.8. FreeBSD 9 is EOL since March 2013 based on Wikipedia-Sensei's data: https://en.wikipedia.org/wiki/FreeBSD -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes: > On Mon, Jan 06, 2020 at 03:53:08AM +0000, Michael Paquier wrote: >> Remove support for OpenSSL 0.9.8 and 1.0.0 > So the buildfarm is not that bad, I have spotted one failure from > nightjar: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2020-01-06%2003%3A54%3A10 As I recall, we'd already decided that nightjar needs to be EOL'd because that version of FreeBSD has nonatomic file rename [1]. You'll probably see failures from some of my dinosaurs too. I've not yet switched them over to using newer OpenSSL, but will do so tomorrow or so. regards, tom lane [1] https://www.postgresql.org/message-id/31bbae1d-1670-df3b-76e6-2e8ff8e66642%402ndQuadrant.com
On Mon, Jan 06, 2020 at 01:58:58PM +0900, Michael Paquier wrote: > So the buildfarm is not that bad, I have spotted one failure from > nightjar: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2020-01-06%2003%3A54%3A10 > > /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c: > In function 'initialize_SSL': > /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: > error: 'SSL_OP_NO_COMPRESSION' undeclared (first use in this function) > /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: > error: (Each undeclared identifier is reported only once > /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-openssl.c:1198: > error: for each function it appears in.) > > And this means that the version likely used here should be 0.9.8. > FreeBSD 9 is EOL since March 2013 based on Wikipedia-Sensei's data: > https://en.wikipedia.org/wiki/FreeBSD And here comes prairiedog, also using OpenSSL 0.9.8 from what I can see: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-01-06%2004%3A56%3A02 -- Michael
Attachment
On Mon, Jan 06, 2020 at 12:06:30AM -0500, Tom Lane wrote: > As I recall, we'd already decided that nightjar needs to be EOL'd > because that version of FreeBSD has nonatomic file rename [1]. Ah, indeed. I forgot this discussion, and that was not long ago. > You'll probably see failures from some of my dinosaurs too. > I've not yet switched them over to using newer OpenSSL, > but will do so tomorrow or so. Thanks! -- Michael
Attachment
On Mon, Jan 6, 2020 at 3:50 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Jan 06, 2020 at 12:06:30AM -0500, Tom Lane wrote:
> As I recall, we'd already decided that nightjar needs to be EOL'd
> because that version of FreeBSD has nonatomic file rename [1].
Ah, indeed. I forgot this discussion, and that was not long ago.
I was going to upgrade it when I could migrate the OS of the host machine to CentOS 8. However, last time I looked some things about Centos 8 (e.g. EPEL) were not mature enough. In any case, to do that requires my physical presence, and I'm currently 10,000 miles or so away from it until mid March. I'll turn off both nightjar and friarbird in the meantime.
cheers
andrew
I wrote:
> You'll probably see failures from some of my dinosaurs too.
> I've not yet switched them over to using newer OpenSSL,
> but will do so tomorrow or so.
I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are
not out of the woods there:
* prairiedog required 6:46 to run the ssl test [1], compared to 3:24
in its last run with 0.9.8x. Why so much slower?
* gaur fell over in the ssl test [2]. I had not asked it to run that
test before, so this may well be a pre-existing issue not something
new with the version change. It looks like something in that test
is assuming that we have IPv6 support, which maybe it shouldn't be,
even in 2020.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-01-06%2015%3A25%3A37
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2020-01-06%2015%3A47%3A18
I wrote:
> * gaur fell over in the ssl test [2]. I had not asked it to run that
> test before, so this may well be a pre-existing issue not something
> new with the version change. It looks like something in that test
> is assuming that we have IPv6 support, which maybe it shouldn't be,
> even in 2020.
Yeah ... SSLServer.pm has code like this:
print $hba
"hostssl trustdb all $serverhost/32 $authmethod\n";
print $hba
"hostssl trustdb all ::1/128 $authmethod\n";
This seems to me to be approximately the worst of all possible worlds.
Not only will this not work on a machine where IPv6 isn't working, but
it's not possible to actually use IPv6 if you want to, because the netmask
for $serverhost is hard-wired. Furthermore, because the client side of
the tests always connects to $serverhost, the IPv6 entries are useless.
All they're doing is letting in connections we don't want, contrary to
the clear comment just above this.
I propose the attached, which removes the unnecessary entries
and puts full control of the IPv4/IPv6 decision in one place
(well, two places). The test will still always connect over IPv4,
but at least there's now a clear route to changing that if
someone wants to.
regards, tom lane
diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl
index 93e2b79..83fcd5e 100644
--- a/src/test/ssl/t/001_ssltests.pl
+++ b/src/test/ssl/t/001_ssltests.pl
@@ -26,6 +26,8 @@ else
# hostname, because the server certificate is always for the domain
# postgresql-ssl-regression.test.
my $SERVERHOSTADDR = '127.0.0.1';
+# This is the pattern to use in pg_hba.conf to match incoming connections.
+my $SERVERHOSTCIDR = '127.0.0.1/32';
# Allocation of base connection string shared among multiple tests.
my $common_connstr;
@@ -66,7 +68,8 @@ $node->start;
my $result = $node->safe_psql('postgres', "SHOW ssl_library");
is($result, 'OpenSSL', 'ssl_library parameter');
-configure_test_server_for_ssl($node, $SERVERHOSTADDR, 'trust');
+configure_test_server_for_ssl($node, $SERVERHOSTADDR, $SERVERHOSTCIDR,
+ 'trust');
note "testing password-protected keys";
diff --git a/src/test/ssl/t/002_scram.pl b/src/test/ssl/t/002_scram.pl
index c08aa19..a6642f8 100644
--- a/src/test/ssl/t/002_scram.pl
+++ b/src/test/ssl/t/002_scram.pl
@@ -20,6 +20,8 @@ if ($ENV{with_openssl} ne 'yes')
# This is the hostname used to connect to the server.
my $SERVERHOSTADDR = '127.0.0.1';
+# This is the pattern to use in pg_hba.conf to match incoming connections.
+my $SERVERHOSTCIDR = '127.0.0.1/32';
# Determine whether build supports tls-server-end-point.
my $supports_tls_server_end_point =
@@ -43,8 +45,8 @@ $ENV{PGPORT} = $node->port;
$node->start;
# Configure server for SSL connections, with password handling.
-configure_test_server_for_ssl($node, $SERVERHOSTADDR, "scram-sha-256",
- "pass", "scram-sha-256");
+configure_test_server_for_ssl($node, $SERVERHOSTADDR, $SERVERHOSTCIDR,
+ "scram-sha-256", "pass", "scram-sha-256");
switch_server_cert($node, 'server-cn-only');
$ENV{PGPASSWORD} = "pass";
$common_connstr =
diff --git a/src/test/ssl/t/SSLServer.pm b/src/test/ssl/t/SSLServer.pm
index 005955a..1e392b8 100644
--- a/src/test/ssl/t/SSLServer.pm
+++ b/src/test/ssl/t/SSLServer.pm
@@ -94,9 +94,12 @@ sub copy_files
return;
}
+# serverhost: what to put in listen_addresses, e.g. '127.0.0.1'
+# servercidr: what to put in pg_hba.conf, e.g. '127.0.0.1/32'
sub configure_test_server_for_ssl
{
- my ($node, $serverhost, $authmethod, $password, $password_enc) = @_;
+ my ($node, $serverhost, $servercidr, $authmethod, $password,
+ $password_enc) = @_;
my $pgdata = $node->data_dir;
@@ -153,7 +156,7 @@ sub configure_test_server_for_ssl
$node->restart;
# Change pg_hba after restart because hostssl requires ssl=on
- configure_hba_for_ssl($node, $serverhost, $authmethod);
+ configure_hba_for_ssl($node, $servercidr, $authmethod);
return;
}
@@ -181,10 +184,10 @@ sub switch_server_cert
sub configure_hba_for_ssl
{
- my ($node, $serverhost, $authmethod) = @_;
+ my ($node, $servercidr, $authmethod) = @_;
my $pgdata = $node->data_dir;
- # Only accept SSL connections from localhost. Our tests don't depend on this
+ # Only accept SSL connections from $servercidr. Our tests don't depend on this
# but seems best to keep it as narrow as possible for security reasons.
#
# When connecting to certdb, also check the client certificate.
@@ -192,21 +195,17 @@ sub configure_hba_for_ssl
print $hba
"# TYPE DATABASE USER ADDRESS METHOD OPTIONS\n";
print $hba
- "hostssl trustdb md5testuser $serverhost/32 md5\n";
+ "hostssl trustdb md5testuser $servercidr md5\n";
print $hba
- "hostssl trustdb all $serverhost/32 $authmethod\n";
+ "hostssl trustdb all $servercidr $authmethod\n";
print $hba
- "hostssl trustdb all ::1/128 $authmethod\n";
+ "hostssl verifydb ssltestuser $servercidr $authmethod clientcert=verify-full\n";
print $hba
- "hostssl verifydb ssltestuser $serverhost/32 $authmethod clientcert=verify-full\n";
+ "hostssl verifydb anotheruser $servercidr $authmethod clientcert=verify-full\n";
print $hba
- "hostssl verifydb anotheruser $serverhost/32 $authmethod clientcert=verify-full\n";
+ "hostssl verifydb yetanotheruser $servercidr $authmethod clientcert=verify-ca\n";
print $hba
- "hostssl verifydb yetanotheruser $serverhost/32 $authmethod clientcert=verify-ca\n";
- print $hba
- "hostssl certdb all $serverhost/32 cert\n";
- print $hba
- "hostssl certdb all ::1/128 cert\n";
+ "hostssl certdb all $servercidr cert\n";
close $hba;
return;
}
On Mon, Jan 06, 2020 at 03:08:25PM -0500, Tom Lane wrote: > I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are > not out of the woods there: > > * prairiedog required 6:46 to run the ssl test [1], compared to 3:24 > in its last run with 0.9.8x. Why so much slower? I have seen the tests being slower depending on the version of OpenSSL pattern, though I think that it came with 1.1.0. I have no bothered digging into that though, but I can notice the difference. -- Michael
Attachment
On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote: > I propose the attached, which removes the unnecessary entries > and puts full control of the IPv4/IPv6 decision in one place > (well, two places). The test will still always connect over IPv4, > but at least there's now a clear route to changing that if > someone wants to. Looks sane to me. Thanks for the fix! -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote:
>> I propose the attached, which removes the unnecessary entries
>> and puts full control of the IPv4/IPv6 decision in one place
>> (well, two places). The test will still always connect over IPv4,
>> but at least there's now a clear route to changing that if
>> someone wants to.
> Looks sane to me. Thanks for the fix!
Pushed, thanks for reviewing!
regards, tom lane
On Mon, Jan 06, 2020 at 05:18:02PM +1030, Andrew Dunstan wrote: > I was going to upgrade it when I could migrate the OS of the host machine > to CentOS 8. However, last time I looked some things about Centos 8 (e.g. > EPEL) were not mature enough. In any case, to do that requires my physical > presence, and I'm currently 10,000 miles or so away from it until mid > March. I'll turn off both nightjar and friarbird in the meantime. Thanks Andrew! Sorry for the trouble :/ -- Michael