Re: svn commit: r1896976 - /httpd/httpd/branches/2.4.x/STATUS

2022-01-19 Thread William A Rowe Jr
On Wed, Jan 19, 2022 at 2:02 AM Ruediger Pluem  wrote:
>
> On 1/18/22 11:03 PM, William A Rowe Jr wrote:
> > On Tue, Jan 18, 2022 at 2:20 PM Ruediger Pluem  wrote:
> >>
> >> On 1/18/22 8:54 PM, Yann Ylavic wrote:
> >>> On Tue, Jan 18, 2022 at 7:48 PM William A Rowe Jr  
> >>> 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 , 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.


Re: svn commit: r1896976 - /httpd/httpd/branches/2.4.x/STATUS

2022-01-19 Thread Ruediger Pluem



On 1/18/22 11:03 PM, William A Rowe Jr wrote:
> On Tue, Jan 18, 2022 at 2:20 PM Ruediger Pluem  wrote:
>>
>> On 1/18/22 8:54 PM, Yann Ylavic wrote:
>>> On Tue, Jan 18, 2022 at 7:48 PM William A Rowe Jr  
>>> 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 , 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