Removal of support for OpenSSL 0.9.8 and 1.0.0 - Mailing list pgsql-hackers

From Michael Paquier
Subject Removal of support for OpenSSL 0.9.8 and 1.0.0
Date
Msg-id 20191205083252.GE5064@paquier.xyz
Whole thread Raw
Responses Re: Removal of support for OpenSSL 0.9.8 and 1.0.0  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Hi all,

So, I have been looking at what we could clean up by removing support
for OpenSSL 0.9.8 and 1.0.0.  Here are my notes:
1) SSL_get_current_compression exists before 0.9.8, and we don't
actually make use of its configure check.  So I think that it could
just be removed, as per patch 0001.
2) SSL_clear_options exists since 0.9.8, so we should not even need the
configure checks.  Still, it is defined as a macro from 0.9.8 to
1.0.2, and then it has switched to a function in 1.1.0, so we fail to
detect it on past versions of OpenSSL (LibreSSL has forked at the
point of 1.0.1g, so it uses only a macro).  There is an extra take
though.  Daniel has mentioned that here:
https://www.postgresql.org/message-id/98F7F99E-1129-41D8-B86B-FE3B1E286881@yesql.se
Note also that a364dfa has also added a tweak in fe-secure-openssl.c
for cases where we don't have SSL_clear_options().  This refers to
NetBSD 5.1.  Peter, do you recall which version of LibreSSL was
involved here?  From a lookup at the code of LibreSSL, the function
has always been around as a macro.  Anyway, 0002 is more subject to
discussions regarding this last point.

Then comes the actual changes across the major versions:
1) SSL_CTX_set_options, which has been added in 0.9.8f, so this could
get removed in be-secure-openssl.c.
2) These functions are new as of 1.0.2:
X509_get_signature_nid
3) These functions are new as of 1.1.0:
- SSL_CTX_set_min_proto_version, SSL_CTX_set_max_proto_version (still
for the fallback functions we have it sounds better to keep the extra
checks on the TLSvXX definitions.)
- BIO_meth_new
- BIO_get_data
- OPENSSL_init_ssl
- ASN1_STRING_get0_data
From the point of view of the code, the cleanup is not actually that
amazing I am afraid, a jump directly to 1.1.0 would remove much more
because the breakages were wider when we integrated it.  Anyway, those
cleanups are part of 0003.  I thought that this would have resulted in
more cleanup :(

I think that 0001 is a fix we need to do, 0002 is debatable still
LibreSSL should support it and we fail to detect SSL_clear_options
properly, and 0003 does not really much additional value.  Or we put
into the balance for 0003 the argument that we can use TLSv1.2 for all
configurations, which is safer but we have the configuration to
enforce it.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Memory-Bounded Hash Aggregation
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum