httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Date Sun, 12 Jan 2014 13:33:55 GMT
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <trawick@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/

Mime
View raw message