Horton
Menu

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Gustafsson <daniel@yesql.se>, Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-30T21:27:44Z
Lists: pgsql-hackers 
On Sun, Mar 31, 2024 at 9:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I was reminded of this thread by ambient security paranoia.  As it
> > stands, we require 1.0.2 (but we very much hope that package
> > maintainers and others in control of builds don't decide to use it).
> > Should we skip 1.1.1 and move to requiring 3 for v17?
>
> I'd be kind of sad if I couldn't test SSL stuff anymore on my
> primary workstation, which has
>
> $ rpm -q openssl
> openssl-1.1.1k-12.el8_9.x86_64
>
> I think it's probably true that <=1.0.2 is not in any distro that
> we still need to pay attention to, but I reject the contention
> that RHEL8 is not in that set.

Hmm, OK so it doesn't have 3 available in parallel from base repos.
But it's also about to reach end of "full support" in 2 months[1], so
if we applied the policies we discussed in the LLVM-vacuuming thread
(to wit: build farm - EOL'd OSes), then...  One question I'm unclear
on is whether v17 will be packaged for RHEL8.

[1] https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20Linux

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove obsolete unconstify()

  2. Only perform pg_strong_random init when required

  3. Remove support for OpenSSL older than 1.1.0

  4. Support SSL_R_VERSION_TOO_LOW when using LibreSSL

  5. Support disallowing SSL renegotiation when using LibreSSL

  6. Doc: Use past tense for things which happened in the past

  7. Remove support for OpenSSL 1.0.1

  8. Remove support for OpenSSL 0.9.8 and 1.0.0