On 16.04.24 10:17, Daniel Gustafsson wrote:
I forgot (and didn't check) that we backpatched 01e6f1a842f4, with that in mind
I agree that we should backpatch 0003 as well to put LibreSSL on par as much as
we can. 0004 is a fix for the LibreSSL support, not adding anything new, so
pushing that to master now makes sense. Unless objections are raised I'll push
0001, 0003 and 0004 shortly. 0002 and 0005 can hopefully be addressed in the
July commitfest.
Review of the latest batch:
* v9-0001-Doc-Use-past-tense-for-things-which-happened-in-t.patch
Ok
8 v9-0002-Remove-support-for-OpenSSL-1.0.2.patch
Ok, but maybe make the punctuation consistent here:
+ # Function introduced in OpenSSL 1.0.2, not in LibreSSL.
+ ['SSL_CTX_set_cert_cb'],
+
+ # Function introduced in OpenSSL 1.1.1, not in LibreSSL
['X509_get_signature_info'],
* v9-0003-Support-disallowing-SSL-renegotiation-in-LibreSSL.patch
ok
* 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.
Also, "OpenSSL 7.2" in the commit message probably meant "OpenBSD"?
* 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?
Conditionally sticking the RAND_poll() into pg_strong_random(), does
that have the effect we want? It wouldn't reinitialize after a fork,
AFAICT.
If everything is addressed, I agree that 0001, 0003, and 0004 can go
into PG17, the rest later.
