On Wed, Apr 11, 2018 at 4:56 PM, Joe Orton <[email protected]> wrote: > On Wed, Apr 11, 2018 at 02:10:27PM +0200, Stefan Eissing wrote: >> What we fixed here is a bug, plain and simple. And if installations rely >> on a bug, they might break on an update. Seems unavoidable. >> >> Nowhere is this "a certificate is visible in other vhosts if it is >> configured in the >> first vhost and the other have no own SSL configuration" documented or even >> specified. >> Quite the opposite, I think. > > I certainly don't find it plain or simple and if that's true for me > I'd bet at least some mod_ssl users are even worse off! > (I had two bug reports from Fedora users already in the few days after > pushing the 2.4.33 update) > > Given that: > > a) the configs worked forever in 2.4, *and* > b) we had to extend the module struct (!!) and a core merging function (!!!) > to > change the behaviour, *and* > c) there was never any warning for this config > > ...I think it quite uncharitable to our users to argue this is not a > regression because > users should have known the old behaviour is a "bug".
I agree... to both Stefan's and your points of view here :p We can hardly break existing configurations, even if they rely on a bug (our bug...). But another user (or the same!) may open a bug when her/his SSLCertificate stops working as soon as any other SSL directive is added to the second vhost (as explained by Stefan), and we should also fix it. Maybe we need a global EXEC_ON_READ setting (before any vhost) to control/ignore AP_MODULE_FLAG_ALWAYS_MERGE? Otherwise broken users are stuck with mod_ssl < 2.4.33 (which may be also an option for dubious compatibility issues). Regards, Yann.
