Re: svn commit: r1556815 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS

2014-01-10 Thread Ruediger Pluem
j...@apache.org wrote: Author: jim Date: Thu Jan 9 14:28:39 2014 New Revision: 1556815 URL: http://svn.apache.org/r1556815 Log: Merge r1524368, r1524388 from trunk: Use apr_socket_timeout_get instead of hard-coded 30 seconds timeout. Use apr_socket_timeout_get instead of

Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c server/request.c ser

2014-01-10 Thread Ruediger Pluem
minf...@apache.org wrote: Author: minfrin Date: Mon Dec 30 19:50:52 2013 New Revision: 1554300 URL: http://svn.apache.org/r1554300 Log: core: Support named groups and backreferences within the LocationMatch, DirectoryMatch, FilesMatch and ProxyMatch directives. Modified:

[VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Jeff Trawick
Open source projects, ASF or otherwise, have varying procedures for commits of fixes to vulnerabilities. One important aspect of these procedures is whether or not fixes to vulnerabilities can be committed to a repository with commit logs and possibly CHANGES entries which purposefully obscure

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Jeff Trawick
[X] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be provided yet. --/-- IMO it is not appropriate to let skilled attackers see a

AW: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Plüm , Rüdiger , Vodafone Group
Von: Jeff Trawick [mailto:traw...@gmail.com] Gesendet: Freitag, 10. Januar 2014 14:39 An: Apache HTTP Server Development List Betreff: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities Open source projects, ASF or otherwise, have varying procedures for commits of

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Jim Jagielski
+1 On Jan 10, 2014, at 8:44 AM, Jeff Trawick traw...@gmail.com wrote: [X] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be

Re: Looking to TR 2.4.8 in Feb...

2014-01-10 Thread Yann Ylavic
Helo, could http://svn.apache.org/r1538776 be considered for backport too (PR 55475)? It's about mod_proxy to detect/handle incomplete (interrupted) backend responses. Regards, Yann.

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Reindl Harald
+1 in some cases re-consider if a used option is really needed and disable it may close a vulnerability, the admin only needs to know that there is danger Am 10.01.2014 15:24, schrieb Jim Jagielski: +1 On Jan 10, 2014, at 8:44 AM, Jeff Trawick traw...@gmail.com wrote: [X] It is mandatory to

Re: Looking to TR 2.4.8 in Feb...

2014-01-10 Thread Yann Ylavic
Also PR 55666, patches starting with https://issues.apache.org/bugzilla/show_bug.cgi?id=55666#c12 have not been reviewed/commited yet. It's about mod_deflate input/output filters to be reentrant when parsing zlib header, so to avoid Zlib: Invalid header or Insufficient data for inflate. Regards.

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Marion Christophe JAILLET
Le 10/01/2014 14:38, Jeff Trawick a écrit : [ ] It is an accepted practice (but not required) to obscure or omit the vulnerability impact in CHANGES or commit log information when committing fixes for vulnerabilities to any branch. [X] It is mandatory to provide best available description

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Noel Butler
On Fri, 2014-01-10 at 08:38 -0500, Jeff Trawick wrote: [ X] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be provided yet.

Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities

2014-01-10 Thread Ben Reser
On 1/10/14, 5:38 AM, Jeff Trawick wrote: [ ] It is an accepted practice (but not required) to obscure or omit the vulnerability impact in CHANGES or commit log information when committing fixes for vulnerabilities to any branch. [ ] It is mandatory to provide best available description and