Am 15.10.2018 um 16:10 schrieb William A Rowe Jr:
Like my beg for getting us to the 2.4.35 release tag, I'd like to
propose we keep patches to branches/2.4.x/ generally within the scope of
straightening out the remaining quirks related to the OpenSSL 1.1.1 API
and library behavior changes (and similar corrections for any alternate
library implementations such as LibreSSL or BoringSSL.)
This isn't a vote per se... just an ask whether we collectively want to
defer all potentially disruptive changes for a release following
2.4.next. We can certainly resume with that next release on an expedited
basis, within a month or few (as opposed to waiting 6 months as has been
typical.)
It appears that dropping in OpenSSL 1.1.1 into a previously working
httpd built against 1.1.0 is not the "plug and play" replacement that
the OpenSSL team originally envisioned, and deliberately building any
previous release of httpd against 1.1.1 is similarly broken.
Thoughts? Other concerns?
I think everyone is aiming for a mostly riskfree 2.4.next. Apart from
the already committed mod_ssl change to unbreak h2 with OpenSSL 1.1.1,
two further mod_ssl backports popped up:
- One is r1828793, prevents crashes for certain configs and is directly
related to the refactoring done for OpenSSL 1.1.1 support (but does
happen for TLS < 1.3). I guess this clearly goes into the "straightening
out the remaining quirks related to the OpenSSL 1.1.1 API" category.
- The other one goes back to the other big refactoring which allowed to
use SSLProxy* directives in <Proxy> containers, first released in 2.4.32
this year. It fixes a missing config merge (very small patch). This is
not related to the OpenSSL 1.1.1 changes but is a small patch fixing a
regression introduced a few months ago. I think it could go into 2.4.37,
but would understand a more restricted approach.
Regards,
Rainer
