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.
