On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <traw...@gmail.com> wrote:
> Open source projects, ASF or otherwise, have varying procedures for > commits of fixes to vulnerabilities. ... > I plan to update http://httpd.apache.org/dev/guidelines.html based on the outcome of the vote. Folks, if you want to express an opinion but haven't yet, please do so before Tuesday. I'll add something very close to the following, unless the vote changes considerably: ---cut here--- Open source projects, ASF or otherwise, have varying procedures for commits of vulnerability fixes. 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 Apache HTTP Server project has decided that it is in the best interest of our users that the initial commit of such code changes to any branch will provide the best description available at that time as well as any available tracking information such as CVE number when committing fixes for vulnerabilities to any branch. Committing of the fix will be delayed until the project determines that all of the information about the issue can be shared. In some cases there are very real benefits to sharing code early even if full information about the issue cannot, including the potential for broader review, testing, and distribution of the fix. This is outweighed by the concern that sharing only the code changes allows skilled analysts to determine the impact and exploit mechanisms but does not allow the general user community to determine if preventative measures should be taken. ---cut here--- > 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. > > -- Born in Roswell... married an alien... http://emptyhammock.com/
