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

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.