Horton
Menu

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Peter Eisentraut <peter@eisentraut.org>, Michael Paquier <michael@paquier.xyz>, Jacob Champion <jacob.champion@enterprisedb.com>, Thomas Munro <thomas.munro@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, mikael.kjellstrom@gmail.com
Date: 2024-04-06T14:04:45Z
Lists: pgsql-hackers 
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 6 Apr 2024, at 08:02, Peter Eisentraut <peter@eisentraut.org> wrote:
>> 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.

I don't think you responded to Peter's point at all.  The way autoconf
is designed to work is explicitly NOT to try to identify the exact
version of $whatever.  Rather, the idea is to probe for the API
features that you want to rely on: functions, macros, struct fields,
or the like.  If you can't point to an important API difference
between 1.0.2 and 1.1.1, why drop support for 1.0.2?

			regards, tom lane

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