From: William A. Rowe Jr <wrowe@apache.org>
Date: Thu, 13 Jan 2022 03:28:31 +0000 (+0000)
Subject: Propose pcre2 support for backport
X-Git-Tag: 2.4.53-rc1-candidate~105
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=21dda2eed19499f8100c122a6e4ef067a4d5e8a0;p=thirdparty%2Fapache%2Fhttpd.git

Propose pcre2 support for backport


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1896976 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/STATUS b/STATUS
index 636c221dc32..4270efead62 100644
--- a/STATUS
+++ b/STATUS
@@ -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