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: Tom Lane <tgl@sss.pgh.pa.us>
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-05-04T08:08:48Z
Lists: pgsql-hackers 
> On 3 May 2024, at 21:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 03.05.24 10:39, Daniel Gustafsson wrote:
>>> They are no-ops when linking against v18, but writing an extension which
>>> targets all supported versions of postgres along with their respective
>>> supported OpenSSL versions make them still required, or am I missing something?
> 
>> I don't think extensions come into play here, since this is libpq, so 
>> only the shared library interface compatibility matters.
> 
> Yeah, server-side extensions don't really seem to be at hazard,
> but doesn't the argument apply to client-side applications and
> libraries that want to work across different PG/OpenSSL versions?

Right, I was using "extension" a bit carelessly, what I meant was client-side
applications using libpq. 

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