[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

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.