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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, mikael(dot)kjellstrom(at)gmail(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date: 2024-04-18 20:26:33
Message-ID: DD4AD68B-511E-422C-A75A-20FD9EDA7AD4@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 18 Apr 2024, at 12:53, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:

> Review of the latest batch:

Thanks for reviewing!

> 8 v9-0002-Remove-support-for-OpenSSL-1.0.2.patch
>
> Ok, but maybe make the punctuation consistent here:

Fixed.

> * v9-0004-Support-SSL_R_VERSION_TOO_LOW-on-LibreSSL.patch
>
> Seems ok, but the reason isn't clear to me. Are there LibreSSL versions that have SSL_R_VERSION_TOO_LOW but not SSL_R_VERSION_TOO_HIGH? Maybe this could be explained better.

LibreSSL doesn't support SSL_R_VERSION_TOO_HIGH at all, they only support
_TOO_LOW starting with the OpenBSD 7.2 release. I've expanded the commit
message to document this.

> Also, "OpenSSL 7.2" in the commit message probably meant "OpenBSD"?

Ah yes, fixed.

> * v9-0005-Remove-pg_strong_random-initialization.patch
>
> I don't understand the reason for this phrase in the commit message: "1.1.1 is being increasingly phased out from production use". Did you mean 1.1.0 there?

Correct, I got lost among the version numbers it seems. Fixed.

> Conditionally sticking the RAND_poll() into pg_strong_random(), does that have the effect we want? It wouldn't reinitialize after a fork, AFAICT.

No I think you're right, my previous version would have worked (but was ugly)
but this doesn't guarantee that. Thinking more about it maybe it's best to
just keep the init function and have a version check for 1.1.0 there, making it
an empty no-op for all other cases. When we move past 1.1.0 due to a new API
requirement we can blow it all away.

> If everything is addressed, I agree that 0001, 0003, and 0004 can go into PG17, the rest later.

Agreed, 0002 and 0005 are clearly for the v18 cycle.

--
Daniel Gustafsson

Attachment Content-Type Size
v10-0001-Doc-Use-past-tense-for-things-which-happened-in-.patch application/octet-stream 1.6 KB
v10-0002-Remove-support-for-OpenSSL-1.0.2.patch application/octet-stream 25.7 KB
v10-0003-Support-disallowing-SSL-renegotiation-in-LibreSS.patch application/octet-stream 2.0 KB
v10-0004-Support-SSL_R_VERSION_TOO_LOW-on-LibreSSL.patch application/octet-stream 1.4 KB
v10-0005-Remove-pg_strong_random-initialization.patch application/octet-stream 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-04-18 20:28:13 Re: improve performance of pg_dump --binary-upgrade
Previous Message Robert Haas 2024-04-18 20:17:07 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs