Horton
Menu

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

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Michael Paquier <michael@paquier.xyz>, Jacob Champion <jacob.champion@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, mikael.kjellstrom@gmail.com
Date: 2024-04-06T06:02:23Z
Lists: pgsql-hackers 
On 05.04.24 23:48, Daniel Gustafsson wrote:
> The reason to expand the check is to ensure that we have the version we want
> for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all that
> commonly done so having to change the version in the check didn't seem that
> invasive to me.

Why do we need to check for the versions at all?  We should just check 
for the functions we need.  At least that's always been the normal 
approach in configure.

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