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.