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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date: 2024-04-03 23:24:25
Message-ID: Zg3lKcq9m89ICtfo@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 03, 2024 at 01:38:50PM -0400, Tom Lane wrote:
> The discussion we had last year concluded that we were OK with
> dropping 1.0.1 support when RHEL6 goes out of extended support
> (June 2024 per this thread, I didn't check it). Seems like we
> should have the same policy for RHEL7. Also, calling Photon 3
> dead because it went EOL three days ago seems over-hasty.

Yeah. A bunch of users of Photon are VMware (or you could say
Broadcom) product appliances, and I'd suspect that quite a lot of them
rely on Photon 3 for their base OS image. Upgrading that stuff is not
easy work in my experience because they need to cope with a bunch of
embedded services.

> Bottom line for me is that pulling 1.0.1 support now is OK,
> but I think pulling 1.0.2 is premature.

Yeah, I guess so. At least that seems like the safest conclusion
currently here. The build-time check on X509_get_signature_info()
would still be required.

I'd love being able to rip out the internal locking logic currently in
libpq as LibreSSL has traces of CRYPTO_lock(), as far as I've checked,
and we rely on its existence.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-03 23:34:04 Re: Parent/child context relation in pg_get_backend_memory_contexts()
Previous Message Jeff Davis 2024-04-03 23:19:02 Re: Built-in CTYPE provider