On Wed, Jan 19, 2022 at 2:02 AM Ruediger Pluem <rpl...@apache.org> wrote:
>
> On 1/18/22 11:03 PM, William A Rowe Jr wrote:
> > On Tue, Jan 18, 2022 at 2:20 PM Ruediger Pluem <rpl...@apache.org> wrote:
> >>
> >> On 1/18/22 8:54 PM, Yann Ylavic wrote:
> >>> On Tue, Jan 18, 2022 at 7:48 PM William A Rowe Jr <wr...@rowe-clan.net> 
> >>> wrote:
> >>>>
> >>>> Hi Joe, Yann and company,
> >>>>
> >>>> please consider this, we will not build against PCRE2 without 
> >>>> pcre2-config
> >>>> installed from a pcre2-dev package. We find PCRE1 with pcre-config and 
> >>>> link
> >>>> to it, no hassle.
> >>>
> >>> My concern is about the defaut, what happens if no --with-pcre or
> >>> --with-pcre=yes is specified?
> >>>
> >>>>
> >>>> If someone went to the trouble of installing pcre2, wouldn't we want
> >>>> to pick that
> >>>> up, even across a patch release?
> >>>
> >>> I think that a lot of systems have both installed (including the -dev
> >>> packages for building) since pcre2 is the only one supported by some
> >>> projects now and at least httpd requires pcre1 (until the next
> >>> release) so it's likely there too already.
> >>> I haven't looked at the configure part of the patch yet, it's possible
> >>> that your proposed backport already picks up pcre1 when both are
> >>> available (which looks the most reasonable to me for 2.4.x), I'm just
> >>> lazily asking..
> >>
> >> I think the default is pcre2:
> >>
> >> https://gist.github.com/wrowe/73f655d13bbe0f12030aa4557e804d8a#file-httpd-2-4-x-pcre2-10-x-patch-L97-L99
> >>
> >> Regards
> >>
> >> RĂ¼diger
> >
> > You are right - pcre2-10.x is the new default of the proposed patch
> > and the behavior of trunk.
> >
> > I do understand that RHEL, Ubuntu, all the other packagers are
> > applying patches on patches even of this abandoned branch.
> >
> > However the author advises us, it's a bad idea to play with pcre
> > arrays on stack. The author advises us that there are known
> > vulnerabilities (known to him) that cannot be fixed on the 8.x branch,
> > owing to the underlying design. Whether we care, since the flaws are
> > mostly in the expressions under the control of the admin, and not the
> > untrusted input against the expressions, I don't know.
>
> Ok. This is a good point. This makes me think of the following:
>
> 1. We should switch the default to pcre2 latest when we have found a solution 
> with pcre2 that
>    avoids the constant memory allocations on heap on each regex execution 
> (see discussion elsewhere on the thread).
> 2. We should clearly state in the CHANGES entry that we switch the default to 
> pcre2 once we do as currently it states:
>
>    *) Support pcre2 (10.x) library in place of the now end-of-life pcre (8.x)
>       for regular expression evaluation. This depends on locating 
> pcre2-config.
>       [William Rowe, Petr Pisar <ppisar redhat.com>, Rainer Jung]
>
>    Which suggests to the user that it *can* use pcre2 if pcre2-config is 
> present, but not it *will* use it if pcre2-config
>    is present.

The key question, do we do this on stack? The library author wisely advises
against our doing this again to avoid stack smashing vectors, and rightly so.
This is the point in time to avoid high-risk coding practices.

So if someone (not me, not this month, too buried) wants to do this... even to
take the suggestion of _ex() functions which have a threadkey tied to the passed
single-threaded pool, I'd be in favor, and it's worth delaying a pcre2-10.x and
openssl 3.0.0 compatible release for just a week or few to work that in.

Reply via email to