git.net

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

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 <ruediger.pluem@xxxxxxxxxxxx>
> Gesendet: Montag, 23. Juli 2018 11:26
> An: dev@xxxxxxxxxxxxxxxx
> 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 <frank.meier@xxxxxxxx>
> > Gesendet: Freitag, 20. Juli 2018 09:26
> > An: dev@xxxxxxxxxxxxxxxx
> > 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 <ylavic.dev@xxxxxxxxx>:
> > >>>
> > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem
> <rpluem@xxxxxxxxxx>
> > 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