pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

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

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&amp;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]/messages/by-id/31bbae1d-1670-df3b-76e6-2e8ff8e66642@2ndQuadrant.com.

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]: /messages/by-id/31bbae1d-1670-df3b-76e6-2e8ff8e66642@2ndQuadrant.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&amp;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&amp;dt=2020-01-06%2004%3A56%3A02
--
Michael

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

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]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&amp;dt=2020-01-06%2015%3A25%3A37, compared to 3:24
in its last run with 0.9.8x. Why so much slower?

* gaur fell over in the ssl test [2]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&amp;dt=2020-01-06%2015%3A47%3A18. 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&amp;dt=2020-01-06%2015%3A25%3A37
[2]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&amp;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

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

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

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