Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
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 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. > > [ ] ___ (fill in the blank) The Subversion project has struggled with this same issue. To the degree that there has actually been a fair amount of thought into how to avoid doing security by obscurity. The processes we've discussed have varied from executing the release entirely hidden from anyone but the PMC to simply publishing an advisory with a patch right before committing to trunk (treating that advisory with patch as a release with appropriate voting handled by PMC members privately). You're always dealing with a certain amount of security by obscurity. The bugs we find often have existed for a long time. If one person can find it someone else certainly could. For all we know the issues may have already been found and only exploited in limited ways such that the issue was never reported. Even with advance notification I've found that the binary packagers can take their sweet time getting security fixes included. Some binary packagers don't really have a process that supports patching (they release one package for each version without a method of identify versions that have been patched). Administrators may not always know what to do with patches. So frankly all of the processes stink. Yet, I think that the best process is to reveal security issues when you can put your best foot forward and have things positioned to get the fixes in the hands of as many users as possible as quickly as possible. I think that's best served by withholding details (even if you're doing so imperfectly) until release or the issue is widely disclosed to the public. It should be noted that not all security issues are equal. For the most part highly critical fixes are rare, when they do come up we could use a release process that hides everything from non-PMC members until release time frame. With other less severe issues possibly just disclosing immediately when we apply the fix. There doesn't need to be a one size fits all answer to this. But I certainly would like to see us have a consistent policy for determining which process to follow. So my vote wouldn't really fit into the options presented above. I'd suggest coming up with a process for varying levels of issues and criteria to determine which process to follow.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
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. > signature.asc Description: This is a digitally signed message part
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
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 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. [ ] ___ (fill in the blank) ---/--- Could be also interesting to be able to deliver quick fix. For example, 2.4.7 is the latest stable version. 2.4.8 has things back-ported from trunk little by little and should be T&R "one day" (in feb ?). Should an important vulnerability be found, then releasing: - a 2.4.7.1or - 2.4.7 SP1or - 2.4.8 and delaying everything already accepted in backport for a later 2.4.9or - whatever else with *only fixes* for this issue, could be interesting. Doing so would avoid time for T&R and avoid releasing something in a hurry. Best regards, CJ
Re: Looking to T&R 2.4.8 in Feb...
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
+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 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. >> >> --/-- >> >> IMO it is not appropriate to let skilled attackers see a code change (which >> they can analyze to determine if there is an impact that they can exploit) >> if you are not going to make it possible for the general user community >> looking at the same commit activity to decide if they need to take an action. signature.asc Description: OpenPGP digital signature
Re: Looking to T&R 2.4.8 in Feb...
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
+1 On Jan 10, 2014, at 8:44 AM, 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. > > --/-- > > IMO it is not appropriate to let skilled attackers see a code change (which > they can analyze to determine if there is an impact that they can exploit) if > you are not going to make it possible for the general user community looking > at the same commit activity to decide if they need to take an action. > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/
AW: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
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 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 the vulnerability and omit any available vulnerability tracking information. (The vulnerabilities I refer to are those which are not already announced or otherwise generally known to the user community, and where the would-be committer knows that a vulnerability is fixed by the code change possibly being committed. Often it will have been discussed previously with fellow httpd developers in a private forum.) [ ] 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 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. [ ] ___ (fill in the blank) ---/--- Obscuring details about a code change (the first choice above) presumably wouldn't be done for a very obvious and high severity vulnerability. I think that the possible justification for following the first choice for a particular fix is that the committer feels that the vulnerability isn't severe enough to completely hide it but it is severe enough that the vulnerability impact shouldn't be publicized until there is a proposed release with the fix which is being tested. Regards Rüdiger
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
[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 code change (which they can analyze to determine if there is an impact that they can exploit) if you are not going to make it possible for the general user community looking at the same commit activity to decide if they need to take an action. -- Born in Roswell... married an alien... http://emptyhammock.com/
[VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
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 the vulnerability and omit any available vulnerability tracking information. (The vulnerabilities I refer to are those which are not already announced or otherwise generally known to the user community, and where the would-be committer knows that a vulnerability is fixed by the code change possibly being committed. Often it will have been discussed previously with fellow httpd developers in a private forum.) [ ] 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 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. [ ] ___ (fill in the blank) ---/--- Obscuring details about a code change (the first choice above) presumably wouldn't be done for a very obvious and high severity vulnerability. I think that the possible justification for following the first choice for a particular fix is that the committer feels that the vulnerability isn't severe enough to completely hide it but it is severe enough that the vulnerability impact shouldn't be publicized until there is a proposed release with the fix which is being tested.
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
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: > httpd/httpd/trunk/CHANGES > httpd/httpd/trunk/include/ap_mmn.h > httpd/httpd/trunk/include/ap_regex.h > httpd/httpd/trunk/include/http_core.h > httpd/httpd/trunk/modules/proxy/mod_proxy.c > httpd/httpd/trunk/modules/proxy/mod_proxy.h > httpd/httpd/trunk/server/core.c > httpd/httpd/trunk/server/request.c > httpd/httpd/trunk/server/util_pcre.c > > Modified: httpd/httpd/trunk/server/util_pcre.c > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_pcre.c?rev=1554300&r1=1554299&r2=1554300&view=diff > == > --- httpd/httpd/trunk/server/util_pcre.c (original) > +++ httpd/httpd/trunk/server/util_pcre.c Mon Dec 30 19:50:52 2013 > #define APR_WANT_STRFUNC > @@ -124,7 +125,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t * > const char *errorptr; > int erroffset; > int errcode = 0; > -int options = 0; > +int options = PCRE_DUPNAMES; This fails to compile on older PCRE versions that do not know PCRE_DUPNAMES, like 6.6 on RHEL 5. How about Index: util_pcre.c === --- util_pcre.c (revision 1556947) +++ util_pcre.c (working copy) @@ -125,7 +125,12 @@ const char *errorptr; int erroffset; int errcode = 0; +/* PCRE_DUPNAMES is only present in more recent versions of PCRE */ +#ifdef PCRE_DUPNAMES int options = PCRE_DUPNAMES; +#else +int options = 0; +#endif if ((cflags & AP_REG_ICASE) != 0) options |= PCRE_CASELESS; instead? > > if ((cflags & AP_REG_ICASE) != 0) > options |= PCRE_CASELESS; Regards Rüdiger
Re: svn commit: r1556815 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS
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 hard-coded 30 seconds timeout. > > Document r1524368 in CHANGES. > > Submitted by: jkaluza > Reviewed/backported by: jim > > Modified: > httpd/httpd/branches/2.4.x/ (props changed) > httpd/httpd/branches/2.4.x/CHANGES > httpd/httpd/branches/2.4.x/STATUS I guess you missed to commit the implementation :-) Regards Rüdiger
