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: Michael Paquier <michael@paquier.xyz>
Cc: Daniel Gustafsson <daniel@yesql.se>, Jacob Champion <jacob.champion@enterprisedb.com>, Thomas Munro <thomas.munro@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, mikael.kjellstrom@gmail.com, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-04-19T08:06:26Z
Lists: pgsql-hackers 
On 19.04.24 07:37, Michael Paquier wrote:
> On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote:
>> If everything is addressed, I agree that 0001, 0003, and 0004 can go into
>> PG17, the rest later.
> 
> About the PG17 bits, would you agree about a backpatch?  Or perhaps
> you disagree?

I don't think any of these need to be backpatched, at least right now.

0001 is just a cosmetic documentation tweak, has no reason to be 
backpatched.

0003 adds new functionality for LibreSSL.  While the code looks 
straightforward, we have little knowledge about how it works in 
practice.  How is the buildfarm coverage of LibreSSL (with SSL tests 
enabled!)?  If people are keen on this, it might be better to get it 
into PG17 and at least let to go through a few months of beta testing.

0004 effectively just enhances an error message for LibreSSL; there is 
little reason to backpatch this.

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