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
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 |