4 day ago, you all saw this. 6 years ago, you all started using this on trunk.
Don't know what I can to do help this along and honor the library author's wishes for all of us to walk away from the dead fork, and use the maintained fork. It's whatever it is, I'm out of here and removing the backport application branch, whoever 3rd upvotes this be prepared to apply this for us all, thanks. On Wed, Jan 12, 2022 at 9:28 PM <wr...@apache.org> wrote: > > Author: wrowe > Date: Thu Jan 13 03:28:31 2022 > New Revision: 1896976 > > URL: http://svn.apache.org/viewvc?rev=1896976&view=rev > Log: > Propose pcre2 support for backport > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1896976&r1=1896975&r2=1896976&view=diff > ============================================================================== > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 13 03:28:31 2022 > @@ -150,6 +150,35 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: > PATCHES PROPOSED TO BACKPORT FROM TRUNK: > [ New proposals should be added at the end of the list ] > > + *) Support PCRE2 (10.x) in place of PCRE (8.x). > + Submitted by: wrowe, Petr Pisar [ppisar redhat.com], rjung > + trunk patches: > + http://svn.apache.org/r1773454 > + http://svn.apache.org/r1773741 > + http://svn.apache.org/r1773742 > + http://svn.apache.org/r1773839 > + http://svn.apache.org/r1773870 > + http://svn.apache.org/r1773882 > + http://svn.apache.org/r1814662 > + http://svn.apache.org/r1881478 > + summarized/conflicts resolved: > + https://gist.github.com/wrowe/73f655d13bbe0f12030aa4557e804d8a > + +1: wrowe > + wrowe notes that the current code drops optimizations, owing to the fact > + that the ovector is a required allocation and is no longer allocated on > + the stack, by design. The correct fix is an apr userdata allocation on > + the appropriate pool, which would be thread-safe, but the actual API of > + ap_regexec[_len]() offers us no pool and isn't suitable for httpd-2.4.x. > + At this time, PCRE 8.45 is EOL and will not receive security updates, > + and taking ovector and other arrays off the stack was in direct reaction > + to the patterns of abuse of previous pcre exploits. So this patch > doesn't > + wait for httpd-2.4 to be retired, it will need to be adopted without the > + existing optimiation. > + jorton: Adding ap_pregexec/_len which pass a pool would also work > + for internal users of this api; not sure if performance > + impact is significant from using malloc here. > + > + > PATCHES/ISSUES THAT ARE BEING WORKED > [ New entries should be added at the START of the list ] > > @@ -256,28 +285,6 @@ PATCHES/ISSUES THAT ARE BEING WORKED > make it nonblocking (by default)? > jim: Non-blocking seems the best way to handle... > > - * Support PCRE2 (10.x) in place of PCRE (8.x). > - Submitted by: wrowe, Petr Pisar [ppisar redhat.com] > - trunk patches: > - http://svn.apache.org/r1773454 > - http://svn.apache.org/r1773741 > - http://svn.apache.org/r1773742 > - http://svn.apache.org/r1773839 > - http://svn.apache.org/r1773870 > - http://svn.apache.org/r1773882 > - wrowe notes that the current code is too inefficient, owing to the fact > - that the ovector is a required allocation and is no longer allocated on > - the stack, by design. The correct fix is an apr userdata allocation on > - the appropriate pool, which would be thread-safe, but the actual API of > - ap_regexec[_len]() offers us no pool. We cannot associate that pool with > - the ap_regex_t, because a single regex may be used by many threads in > - parallel and is not thread-safe beyond initialization. > - So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to > write > - this as a thread safe storage buffer for the majority of cases (<10 > $args) > - and we don't have a portable tls mechanism to do so. > - jorton: Adding ap_pregexec/_len which pass a pool would also work > - for internal users of this api; not sure if performance > - impact is significant from using malloc here. > > PATCHES/ISSUES THAT ARE STALLED > > >
