AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Wrong revision. Correct one is r1836472. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Plüm, Rüdiger, Vodafone Group > Gesendet: Montag, 23. Juli 2018 11:26 > An: dev@httpd.apache.org > Betreff: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34 > > This is now backported to 2.4.x as r1555631 and will be part of the next > release. > > Regards > > Rüdiger > > > -Ursprüngliche Nachricht- > > Von: Frank Meier > > Gesendet: Freitag, 20. Juli 2018 09:26 > > An: dev@httpd.apache.org > > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34 > > > > > > On 18/07/18 13:57, Ruediger Pluem wrote: > > > > > > On 07/18/2018 11:44 AM, Stefan Eissing wrote: > > >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic : > > >>> > > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem > > > wrote: > > >>>> Good catch. Maybe a dirty working copy during backport? Yann? > > >>> Actually the change was in the proposed patch: > > >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl- > ocsp- > > enable-leaf.patch > > >>> A subtle difference between trunk and 2.4.x, around the change... > > >> Hmm, so I had the dirty working dir when creating the patch? I do > not > > remember messing with that setting, but obviously I was mistaken in > > doing it. > > >> > > >> So, patch 1 it is then, Rainer? > > >> > > > I changed my mind :-) Let's backport r1555631 from trunk which is > more > > or less patch 2. So we have aligned trunk and > > > 2.4.x here. r1555631 does not apply clean though, because r1826995, > > r1827001 are already backported, but this is fixable. > > > > > > Regards > > > > > > Rüdiger > > Thanks Guys, so we will run with patch 2. For now. > > Just for other people to know if they hit this issue with 2.4.34 and > are > > not able to patch, there is a workaround: Explicitly setting the > > directive "SSLOCSPOverrideResponder" to "off" in the configuration > file > > does also "fix" the issue. > > > > Cheers, Frank
AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
This is now backported to 2.4.x as r1555631 and will be part of the next release. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Frank Meier > Gesendet: Freitag, 20. Juli 2018 09:26 > An: dev@httpd.apache.org > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34 > > > On 18/07/18 13:57, Ruediger Pluem wrote: > > > > On 07/18/2018 11:44 AM, Stefan Eissing wrote: > >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic : > >>> > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem > wrote: > Good catch. Maybe a dirty working copy during backport? Yann? > >>> Actually the change was in the proposed patch: > >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp- > enable-leaf.patch > >>> A subtle difference between trunk and 2.4.x, around the change... > >> Hmm, so I had the dirty working dir when creating the patch? I do not > remember messing with that setting, but obviously I was mistaken in > doing it. > >> > >> So, patch 1 it is then, Rainer? > >> > > I changed my mind :-) Let's backport r1555631 from trunk which is more > or less patch 2. So we have aligned trunk and > > 2.4.x here. r1555631 does not apply clean though, because r1826995, > r1827001 are already backported, but this is fixable. > > > > Regards > > > > Rüdiger > Thanks Guys, so we will run with patch 2. For now. > Just for other people to know if they hit this issue with 2.4.34 and are > not able to patch, there is a workaround: Explicitly setting the > directive "SSLOCSPOverrideResponder" to "off" in the configuration file > does also "fix" the issue. > > Cheers, Frank
Re: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Proposed for backport as r1836334. Regards Rüdiger On 07/19/2018 11:23 AM, Plüm, Rüdiger, Vodafone Group wrote: > I can do tomorrow and make a proposal in STATUS. Looks like we are all > aligned now how to resolve this. > > Regards > > Rüdiger > >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing >> Gesendet: Donnerstag, 19. Juli 2018 11:10 >> An: dev@httpd.apache.org >> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34 >> >> You'll take care of it, Rüdiger? >> >>> Am 18.07.2018 um 13:57 schrieb Ruediger Pluem : >>> >>> >>> >>> On 07/18/2018 11:44 AM, Stefan Eissing wrote: > Am 18.07.2018 um 11:37 schrieb Yann Ylavic : > > On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem >> wrote: >> >> Good catch. Maybe a dirty working copy during backport? Yann? > > Actually the change was in the proposed patch: > https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp- >> enable-leaf.patch > A subtle difference between trunk and 2.4.x, around the change... Hmm, so I had the dirty working dir when creating the patch? I do not >> remember messing with that setting, but obviously I was mistaken in >> doing it. So, patch 1 it is then, Rainer? >>> >>> I changed my mind :-) Let's backport r1555631 from trunk which is more >> or less patch 2. So we have aligned trunk and >>> 2.4.x here. r1555631 does not apply clean though, because r1826995, >> r1827001 are already backported, but this is fixable. >>> >>> Regards >>> >>> Rüdiger >
AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
I can do tomorrow and make a proposal in STATUS. Looks like we are all aligned now how to resolve this. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 19. Juli 2018 11:10 > An: dev@httpd.apache.org > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34 > > You'll take care of it, Rüdiger? > > > Am 18.07.2018 um 13:57 schrieb Ruediger Pluem : > > > > > > > > On 07/18/2018 11:44 AM, Stefan Eissing wrote: > >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic : > >>> > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem > wrote: > > Good catch. Maybe a dirty working copy during backport? Yann? > >>> > >>> Actually the change was in the proposed patch: > >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp- > enable-leaf.patch > >>> A subtle difference between trunk and 2.4.x, around the change... > >> > >> Hmm, so I had the dirty working dir when creating the patch? I do not > remember messing with that setting, but obviously I was mistaken in > doing it. > >> > >> So, patch 1 it is then, Rainer? > >> > > > > I changed my mind :-) Let's backport r1555631 from trunk which is more > or less patch 2. So we have aligned trunk and > > 2.4.x here. r1555631 does not apply clean though, because r1826995, > r1827001 are already backported, but this is fixable. > > > > Regards > > > > Rüdiger
