Retire support for OpenSSL 1.1.1 due to raised API requirements
Commit a70e01d430 removed support for OpenSSL 1.0.2 in order to simplify the
code by removing the need for finicky initialization of the library. Based on
our API usage the new minimum version was defined as 1.1.0.
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.
The attached is the 0001 from the above mentioned patchset for illustration.
The removal should happen when pushing the rest of the patchset.
Does anyone see any reason not to go to 1.1.1 as the minimum?
--
Daniel Gustafsson
Attachments:
v5-0001-Raise-the-minimum-supported-OpenSSL-version-to-1..patchapplication/octet-stream; name=v5-0001-Raise-the-minimum-supported-OpenSSL-version-to-1..patch; x-unix-mode=0644Download+19-20
Daniel Gustafsson <daniel@yesql.se> writes:
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.
Yeah ... the alternative would be to conditionally compile the new
functionality. That doesn't seem like a productive use of developer
time if it's supporting just one version that should be extinct in
the wild by now.
regards, tom lane
On 9 Sep 2024, at 16:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for configuring cipher suites in TLS 1.3 handshakes require an API available in
OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that we
remove support for OpenSSL 1.1.0 and set the minimum required version to 1.1.1.
OpenSSL 1.1.0 was EOL in September 2019 and was never an LTS version, so it's
not packaged in anything anymore AFAICT and should be very rare in production
use in conjunction with an updated postgres. 1.1.1 LTS will be 2 years EOL by
the time v18 ships so I doubt this will be all that controversial.Yeah ... the alternative would be to conditionally compile the new
functionality. That doesn't seem like a productive use of developer
time if it's supporting just one version that should be extinct in
the wild by now.
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.
--
Daniel Gustafsson
On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.
The cleanup induced by the removal of 1.1.0 is minimal. I'm on board
about your argument with SSL_CTX_set_ciphersuites() to drop 1.1.0 and
simplify the other feature.
I was wondering about HAVE_SSL_CTX_SET_NUM_TICKETS for a few seconds,
but morepork that relies on LibreSSL 3.3.2 disagrees with me.
--
Michael
On 10 Sep 2024, at 00:53, Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
that level for some time, but 1.1.0 is gone from production use.The cleanup induced by the removal of 1.1.0 is minimal. I'm on board
about your argument with SSL_CTX_set_ciphersuites() to drop 1.1.0 and
simplify the other feature.
Yeah, the change to existing code is trivial but avoiding adding a kluge to
handle versions without the relevant API will save complexity. Thanks for
review.
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
--
Daniel Gustafsson
On Tue, Sep 10, 2024 at 10:44:42AM +0200, Daniel Gustafsson wrote:
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
As you wish ;)
--
Michael
On 10 Sep 2024, at 10:44, Daniel Gustafsson <daniel@yesql.se> wrote:
This change will be committed together with the TLSv1.3 cipher suite pathcset,
just wanted to bring it up here and not hide it in another thread.
In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum
version would bump the minimum version of libressl to 3.4, whcih corresponds to
the OpenBSD 3.4 release (from October 2021). The OpenBSD project only supports
the two last releases (7.7 will be the latest by the time v18 ships it seems)
and I assume LibreSSL follows that since they don't state anything else AFAICT.
To keep this from being buried on another thread I figured I'd bring it up here
as well.
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.
--
Daniel Gustafsson
On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson <daniel@yesql.se> wrote:
In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum
version would bump the minimum version of libressl to 3.4, whcih corresponds to
the OpenBSD 3.4 release (from October 2021).
OpenBSD 7.0, that is.
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.
+1
--Jacob
On Thu, Oct 03, 2024 at 08:54:49AM -0700, Jacob Champion wrote:
On Thu, Oct 3, 2024 at 3:17 AM Daniel Gustafsson <daniel@yesql.se> wrote:
We don't explicitly mention which libressl version we support, if we raise it
as proposed here then perhaps it's a good time to state that in the docs.+1
It's pretty clear that we are maintaining it, so +1 to do that and
also mention that libressl falls under the --with-ssl=openssl flag.
--
Michael
This has now been committed via the TLS 1.3 ciphersuite patchset.
--
Daniel Gustafsson