Re: VOTE: Retire libapreq-1.34?
On 05/19/11 18:00, William A. Rowe Jr. wrote: On 5/19/2011 12:46 PM, Philip M. Gollucci wrote: 4) mark svn branch as r/o FWIW, we left 1.3 svn r/w on httpd, if only to document any security patches published long after 1.3 releases are over. Thanks wrowe, thats the project I was trying to follow here. we'll do the same. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Infrastructure,Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: ap_regexec API for buffers (not NULL terminated strings)
On 19 May 2011, at 1:06 PM, Yehezkel Horowitz wrote: Can anyone explain why ap_regexec can take only NULL terminated string? I’m working in filter context and want to run regular expression on bucket content (so I have the buffer length). Currently I had to copy the bucket content and add the NULL at the end before passing it to ap_regexec (this is a waste of CPU and memory). The underling PCRE engine support getting the length of the input string (actually ap_regexec just run strlen on the string and pass the result to pcre_exec) Can you consider adding API for this? (Of course it will get the input length as argument) Similar request (from 2002) could be found at http://www.mail-archive.com/dev@httpd.apache.org/msg12986.html but without any reply. Sounds like a sensible thing to have. Is there a patch for this anywhere that we can take a look at, or is this just a suggestion at this point? Regards, Graham --
RE: ap_regexec API for buffers (not NULL terminated strings)
I have a patch (based on 2.2.17) to where should I submit it? From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Thursday, May 19, 2011 2:23 PM To: dev@httpd.apache.org Cc: Anatoli Tubman; Ethan Schorer Subject: Re: ap_regexec API for buffers (not NULL terminated strings) On 19 May 2011, at 1:06 PM, Yehezkel Horowitz wrote: Can anyone explain why ap_regexec can take only NULL terminated string? I'm working in filter context and want to run regular expression on bucket content (so I have the buffer length). Currently I had to copy the bucket content and add the NULL at the end before passing it to ap_regexec (this is a waste of CPU and memory). The underling PCRE engine support getting the length of the input string (actually ap_regexec just run strlen on the string and pass the result to pcre_exec) Can you consider adding API for this? (Of course it will get the input length as argument) Similar request (from 2002) could be found at http://www.mail-archive.com/dev@httpd.apache.org/msg12986.html but without any reply. Sounds like a sensible thing to have. Is there a patch for this anywhere that we can take a look at, or is this just a suggestion at this point? Regards, Graham -- Scanned by Check Point Total Security Gateway.
Re: ap_regexec API for buffers (not NULL terminated strings)
On 19 May 2011, at 1:24 PM, Yehezkel Horowitz wrote: I have a patch (based on 2.2.17) to where should I submit it? Add it to bugzilla so it doesn't get lost, and then ping here, so someone can pick it up. Ideally, the patch should apply to httpd-trunk first, but having a v2.2 patch also (assuming the trunk one doesn't apply as is) makes it easier to propose for backport. Regards, Graham --
RE: ap_regexec API for buffers (not NULL terminated strings)
Hi Graham I have opened record #51231 in bugzilla (patch attached to the record). https://issues.apache.org/bugzilla/show_bug.cgi?id=51231 Thanks Yehezkel From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Thursday, May 19, 2011 2:33 PM To: dev@httpd.apache.org Subject: Re: ap_regexec API for buffers (not NULL terminated strings) On 19 May 2011, at 1:24 PM, Yehezkel Horowitz wrote: I have a patch (based on 2.2.17) to where should I submit it? Add it to bugzilla so it doesn't get lost, and then ping here, so someone can pick it up. Ideally, the patch should apply to httpd-trunk first, but having a v2.2 patch also (assuming the trunk one doesn't apply as is) makes it easier to propose for backport. Regards, Graham --
Re: [VOTE] Release httpd 2.3.12 as beta
I will reroll the dependency tarball, once the apr/apu vote passes... Once that happens I'll allow for 24 hrs for comments/issues on that tarball and then release/announce.
Re: ap_regexec API for buffers (not NULL terminated strings)
On 19 May 2011, at 12:22, Graham Leggett wrote: On 19 May 2011, at 1:06 PM, Yehezkel Horowitz wrote: Can anyone explain why ap_regexec can take only NULL terminated string? Presumably because that's what PCRE supports! Sounds like a sensible thing to have. Indeed, I could certainly use it. But surely this should be an enhancement request for PCRE. Once they have it, wrapping the API for HTTPD becomes trivial! Anyone sufficiently familiar with regexp internals to say what it would take? -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
RE: ap_regexec API for buffers (not NULL terminated strings)
Hi Nick As I mentioned in my original mail, PCRE DO support getting the length as argument! Please take a short look at ap_regexec implementation (util_pcre.c file) and you will see that current code pass PCRE the length (which is obtained with strlen). So it is just change in HTTPD wrapping API! Best regards, Yehezkel -Original Message- From: Nick Kew [mailto:n...@webthing.com] Sent: Thursday, May 19, 2011 5:27 PM To: dev@httpd.apache.org Subject: Re: ap_regexec API for buffers (not NULL terminated strings) On 19 May 2011, at 12:22, Graham Leggett wrote: On 19 May 2011, at 1:06 PM, Yehezkel Horowitz wrote: Can anyone explain why ap_regexec can take only NULL terminated string? Presumably because that's what PCRE supports! Sounds like a sensible thing to have. Indeed, I could certainly use it. But surely this should be an enhancement request for PCRE. Once they have it, wrapping the API for HTTPD becomes trivial! Anyone sufficiently familiar with regexp internals to say what it would take? -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html Scanned by Check Point Total Security Gateway.
Re: ap_regexec API for buffers (not NULL terminated strings)
On 19 May 2011, at 15:27, Nick Kew wrote: Presumably because that's what PCRE supports! Aaargh! Ignore that. Saw your post and read it as regcomp. The suggestion is totally sensible as well as trivial. Thank you. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: [VOTE] Release httpd 2.3.12 as beta
On 5/19/2011 8:45 AM, Jim Jagielski wrote: I will reroll the dependency tarball, once the apr/apu vote passes... Once that happens I'll allow for 24 hrs for comments/issues on that tarball and then release/announce. +1 Once apr/apu votes are in process, I will roll 2.2.19. Allowing 24 hours for the 2.2.19 vote concurrent to the apr/apu votes, I plan to wait for the mirrors to catch up, then announce.
Re: FYI... I'm planning to TR apr-1.4.5, apr-util-1.3.12 soon
[Resending from correct address] Eric, do you have a moment to look at the httpd issues below, while this is all fresh on you mind? On 5/19/2011 11:07 AM, olli hauer wrote: On 2011-05-19 14:08, Jeff Trawick wrote: On Wed, May 18, 2011 at 2:53 PM, olli hauer oha...@gmx.de wrote: On 2011-05-18 20:20, Jeff Trawick wrote: It turns out that httpd 2.2.18 has a binary ABI breakage bug which will require a re-roll. If we have our 1.4.4/1.3.11 regressions (Windows debug log, ldap pool cleanup, fnmatch edge case) resolved in new releases in time, that would be great for all. If you're aware of any regressions for which a fix hasn't been committed, please follow up on this thread. Releases will need to happen pretty quickly to avoid slowing down httpd 2.2.19 too much. Hi Jeff, I'm just preparing a test build against apache-2.2.18 with 1200+ ports. I can report broken builds if they are apr-1.4.4/httpd-2.2.18 related. It needs some hours until I have the results. But please don't request/ expect a functionality ;) I don't think we'll wait more than 10 more hours on the TR of apr-1.4.5, barring any further news of regression. If you have any results in the meantime, we'll be eager to hear. Hi Jeff, the last ports where build right now ... I've overseen some port which had KDE or Gnome as dependency and those blocked build my build machine the whole night. build system FreeBSD-8.2 (amd64) apr was build with the following parameters and with this fix applied. http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/Makefile.in?r1=1101301r2=1101300pathrev=1101301 apr-1.4.4 $ ./configure --prefix=/usr/local --with-installbuilddir=/usr/local/share/apr/build-1 --enable-threads --enable-ipv6 --with-devrandom apr-util-1.3.11: $ ./configure --prefix=/usr/local --with-apr=/work/a/ports/devel/apr1/work/apr-1.4.4 --with-expat=/usr/local --with-iconv=/usr/local --with-gdbm=/usr/local --with-berkeley-db=/usr/local/include/db47:/usr/local/lib/db47 --without-ndbm --without-ldap --without-mysql --without-pgsql --without-sqlite3 = No apr related build failures in ~1500 ports. Build failures related to the following change in httpd-2.2.18 http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?view=diffr1=1082195r2=1082196pathrev=1082196 https://neon1.net/mod_auth_pubtkt/ --- mod_auth_pubtkt.c: In function 'cookie_match': mod_auth_pubtkt.c:404: error: too few arguments to function 'ap_unescape_url_keep2f' apxs:Error: Command failed with rc=65536 http://code.google.com/p/modmellon/ --- auth_mellon_util.c: In function 'am_urldecode': auth_mellon_util.c:343: error: too few arguments to function 'ap_unescape_url_keep2f' apxs:Error: Command failed with rc=65536 olli
[Announce] Regressions in httpd 2.2.18, apr 1.4.4, and apr-util 1.3.11
New releases are in progress for each of these projects and are
expected to be available in the coming days. The upcoming httpd
2.2.19 will bundle new releases of apr and apr-util which correct
the regressions described below. An announcement of these releases
will be broadcast.
Note: httpd 2.2.18 bundles apr 1.4.4 and apr-util 1.3.11.
Summary of regressions:
httpd 2.2.18: The ap_unescape_url_keep2f() function signature was changed.
This breaks binary compatibility of a number of third-party modules. In
addition, a regression in apr 1.4.4 (see below) could cause httpd to hang.
apr 1.4.4: A fix in apr 1.4.4 apr_fnmatch() to address CVE-2011-0419
introduced a new vulnerability. A patch is attached and should be used
if httpd workers enter a hung state (100% cpu utilization) after updating
to httpd 2.2.18 or apr-util 1.4.4, or if hangs are seen in other apr
applications which use apr_fnmatch().
apr-util 1.3.11: A fix to LDAP support in apr-util 1.3.11 could cause
crashes with httpd's mod_authnz_ldap in some situations.
--- srclib\apr\strings\apr_fnmatch.orig Mon May 02 23:51:24 2011
+++ srclib\apr\strings\apr_fnmatch.cWed May 18 13:09:52 2011
@@ -196,7 +196,10 @@
const char *mismatch = NULL;
int matchlen = 0;
-while (*pattern)
+if (*pattern == '*')
+goto firstsegment;
+
+while (*pattern *string)
{
/* Match balanced slashes, starting a new segment pattern
*/
@@ -207,6 +210,7 @@
++string;
}
+firstsegment:
/* At the beginning of each segment, validate leading period behavior.
*/
if ((flags APR_FNM_PERIOD) (*string == '.'))
@@ -361,9 +365,9 @@
return APR_FNM_NOMATCH;
}
-/* pattern is at EOS; if string is also, declare success
+/* Where both pattern and string are at EOS, declare success
*/
-if (!*string)
+if (!*string !*pattern)
return 0;
/* pattern didn't match to the end of string */
Re: FYI... I'm planning to TR apr-1.4.5, apr-util-1.3.12 soon
On Thu, May 19, 2011 at 12:23 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: [Resending from correct address] Eric, do you have a moment to look at the httpd issues below, while this is all fresh on you mind? On 5/19/2011 11:07 AM, olli hauer wrote: On 2011-05-19 14:08, Jeff Trawick wrote: On Wed, May 18, 2011 at 2:53 PM, olli hauer oha...@gmx.de wrote: On 2011-05-18 20:20, Jeff Trawick wrote: It turns out that httpd 2.2.18 has a binary ABI breakage bug which will require a re-roll. If we have our 1.4.4/1.3.11 regressions (Windows debug log, ldap pool cleanup, fnmatch edge case) resolved in new releases in time, that would be great for all. If you're aware of any regressions for which a fix hasn't been committed, please follow up on this thread. Releases will need to happen pretty quickly to avoid slowing down httpd 2.2.19 too much. Hi Jeff, I'm just preparing a test build against apache-2.2.18 with 1200+ ports. I can report broken builds if they are apr-1.4.4/httpd-2.2.18 related. It needs some hours until I have the results. But please don't request/ expect a functionality ;) I don't think we'll wait more than 10 more hours on the TR of apr-1.4.5, barring any further news of regression. If you have any results in the meantime, we'll be eager to hear. Hi Jeff, the last ports where build right now ... I've overseen some port which had KDE or Gnome as dependency and those blocked build my build machine the whole night. build system FreeBSD-8.2 (amd64) apr was build with the following parameters and with this fix applied. http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/Makefile.in?r1=1101301r2=1101300pathrev=1101301 apr-1.4.4 $ ./configure --prefix=/usr/local --with-installbuilddir=/usr/local/share/apr/build-1 --enable-threads --enable-ipv6 --with-devrandom apr-util-1.3.11: $ ./configure --prefix=/usr/local --with-apr=/work/a/ports/devel/apr1/work/apr-1.4.4 --with-expat=/usr/local --with-iconv=/usr/local --with-gdbm=/usr/local --with-berkeley-db=/usr/local/include/db47:/usr/local/lib/db47 --without-ndbm --without-ldap --without-mysql --without-pgsql --without-sqlite3 = No apr related build failures in ~1500 ports. Build failures related to the following change in httpd-2.2.18 http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?view=diffr1=1082195r2=1082196pathrev=1082196 https://neon1.net/mod_auth_pubtkt/ --- mod_auth_pubtkt.c: In function 'cookie_match': mod_auth_pubtkt.c:404: error: too few arguments to function 'ap_unescape_url_keep2f' apxs:Error: Command failed with rc=65536 http://code.google.com/p/modmellon/ --- auth_mellon_util.c: In function 'am_urldecode': auth_mellon_util.c:343: error: too few arguments to function 'ap_unescape_url_keep2f' apxs:Error: Command failed with rc=65536 This seems to be what we undid here (queued up for 2.2.19) : http://svn.apache.org/viewvc?view=revisionrevision=1124515
Re: VOTE: Retire libapreq-1.34?
Okay so this is the second time this passed. What do we need to do to make this actually happen ? 1) HEADS up e-mail to announce lists, dev list 2) update website 3) update /dist and move to archive 4) mark svn branch as r/o drink beer. On 05/18/11 17:12, Philip M. Gollucci wrote: We already voted on this a while ago. But +1 clearly. You really mean to ask about the whole 1.3Z series. On 04/27/11 13:09, Joe Schaefer wrote: +1 - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-...@httpd.apache.org Sent: Wed, April 27, 2011 8:34:28 AM Subject: Re: VOTE: Retire libapreq-1.34? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/04/2011 15:31, Issac Goldstand wrote: [+1] Remove libapreq-1.34 immediately from www.apache.org/dist/ and CPAN remove it from the download.html page and add a sentence stating that the 1.3 line of releases is at archives.a.o and backpan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk24DVQACgkQ7bEFiW+VIthtuQCgpriVeIu2vhIr77KAbyu3N0Hz lIgAoK63v/K2e0QMP/r6X8MOKG26mpNf =GTuK -END PGP SIGNATURE- -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Infrastructure,Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: FYI... I'm planning to TR apr-1.4.5, apr-util-1.3.12 soon
On 5/19/2011 12:42 PM, Eric Covener wrote: This seems to be what we undid here (queued up for 2.2.19) : http://svn.apache.org/viewvc?view=revisionrevision=1124515 Yes, of course. Sorry, I read through it too quickly and thought it was an internal build failure of either 2.2.18 or 2.2.x branch. I think we are good to go with 2.2.19 once APR is ready to tag.
