On 1/14/14, 7:35 AM, Jeff Trawick wrote: > The simple answer to all of this is "look how httpd releases with security > fixes have been handled in the past." The RM commits the fixes just before > Tag > & Roll and, depending on the impact of the vulnerabilities, may call for an > abbreviated testing schedule.
That really doesn't answer any of the questions I just asked. If I thought the existing process handled all of this I wouldn't have asked the questions. > This is back to choice 1 or choice 2, and whether or not you think that > showing > the code gives a would-be attacker useful information. Committing the code always gives a would-be attacker useful information, I don't dispute that. The distinction is that committing a CVE number with a security fix gives them MORE information. It creates the opportunity to automate detection of fixes that can be analyzed and exploited before we can get fixes in the hands of our users. If you don't narrow the gap between that commit and putting the fix in a usable state to end users then you've harmed our users rather than helped them in my opinion. There will always be some sort of gap, that's just the nature of an open source project. And less critical issues can afford a larger gap than more critical issues. However, that gap should be no more than a few days in my opinion. Certainly not weeks or months. > The vote is about reaffirming support for and documenting a long-standing > practice around commit/disclosure which has been followed in the vast majority > of cases and which most of us feel should always be followed. It is not about > inventing completely new procedures to deal with vulnerabilities. My observation has been that we haven't been doing that. I decided to go back and look at what we've been doing. I only bothered to look at 2.4.x (which I realize is not a huge sample). Here's how we've done with 2.4.x so far: CVE-2013-1896 trunk revision: 1485668 (2013-05-23) CVE in commit: no CVE (even now) comments: mentions segfault release with fix: 2013-07-22 CVE-2013-2249 trunk revision: 1488158 (2013-05-31) CVE in commit: no CVE (even now) comments: doesn't mention security impact at all release with fix: 2013-07-22 CVE-2012-3499 trunk revision: 1413732 (2012-11-26) & 1418752 (2012-12-08) CVE in commit: no CVE (even now) comments: only says missing html escaping release with fix: 2013-02-25 CVE-2012-4558 trunk revision: 1413732 (2012-11-26) CVE in commit: no CVE (even now) comments: only says missing html escaping release with fix: 2013-02-25 CVE-2012-3502 trunk revision: 1373955 (2012-08-16) CVE in commit: no CVE original version: http://mail-archives.apache.org/mod_mbox/httpd-cvs/201208.mbox/%3C20120816175451.51AC32388900%40eris.apache.org%3E has been updated since to include CVE comments: no mention of security impact in initial commit, subsequent update is good release with fix: 2012-08-21 CVE-2012-2687 trunk revision: 1349905 (2012-06-13) CVE in commit: CVE in initial commit comments: Good explanation of security issue release with fix: 2012-08-21 CVE-2012-0883 trunk revision: 1296428 (2012-03-02) CVE in commit: CVE in initial commit comments: Explanation done in initial commit release with fix: 2012-04-17 Now the last couple actually do commit with a CVE number and an exmplation, so maybe I'm wrong and this has been a long standing practice. From the limited data of 2.4.x it looks like something changed (or maybe it's just some people do things one way and another group does it another). To that end I applaud your effort to standardize what's being done. Maybe the people committing obscured logs were following this page: http://www.apache.org/security/committers.html But up till now I've been approaching this as a change in policy since that's how it appeared to me based on the above. > For this small aspect of the overall policy that is being voted on, > implementation is as simple as having the security team determine whether or > not a vulnerability can be fully disclosed prior to the time a release is > prepared. If it can, commit away. If not, wait for Tag&Roll. I acknowledged that my questions went beyond the simple question in your vote. The goal as I understand it is to avoid security by obscurity and to put our users on a equal footing to potential attackers reading our source commits. I don't think ever committing with some sort of security issue explained in the commit message and without an advisory and/or release coming out very soon is ever really helpful towards that goal. Our users do not read our commits, probably do not understand what our commit messages mean with respect to impact and may not be able to apply the fix committed (especially if it doesn't easily apply to release branches). I'm approaching this from the standpoint of helping our users as much as possible.