Horton
Menu

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

Daniel Gustafsson <daniel@yesql.se>

View thread
From: Daniel Gustafsson <daniel@yesql.se>
To: Peter Eisentraut <peter@eisentraut.org>
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-06T07:12:01Z
Lists: pgsql-hackers 
> On 6 Apr 2024, at 08:02, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
> 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.

We could, but finding a stable set of functions which identifies the version of
OpenSSL *and* LibreSSL that we want, and their successors, while not matching
any older versions seemed more opaque than testing two numeric values.  The
suggested check is modelled on the LDAP check which tests for an explicit
version in a header file (albeit not for erroring out).

--
Daniel Gustafsson

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