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.
Regards
Rüdiger
