Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A7BED10F89 for ; Sun, 12 Jan 2014 13:34:49 +0000 (UTC) Received: (qmail 9035 invoked by uid 500); 12 Jan 2014 13:34:32 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 8951 invoked by uid 500); 12 Jan 2014 13:34:26 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 8942 invoked by uid 99); 12 Jan 2014 13:34:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Jan 2014 13:34:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.215.45 as permitted sender) Received: from [209.85.215.45] (HELO mail-la0-f45.google.com) (209.85.215.45) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Jan 2014 13:34:16 +0000 Received: by mail-la0-f45.google.com with SMTP id b8so2737289lan.32 for ; Sun, 12 Jan 2014 05:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6EbN/XII0qp8eZewRcJGS/ZkDMn7Q8ayJHq1pamhpL4=; b=NTgrHgoxBLLQsknd5sAAZj12RT1LGaczALXb+w1XJugFX2RL/qf9lNpwFY/LW2wVlQ PMh8LDMgkg1clBHKumpkNZVXL1pCMxMpqFZGidcNT7HLMnMxL4n3RADH7qfd8Ge/QEDo F50WeBk/nRMdkkiTZOApe+UYb1ZoMJ7TJ3SRyESGix/nDisyB4iGZ5a3POy0DinKe+Z3 Aq2nkrTRGyelUNobQtcyQE2xxGOHj0mV8jonB99b+XZfBnJXRaagLwbuejAW3hgKo8JS j6ZXxc9Rqzafr+fcIhLhy0591aLV2VRFDGCMOPhOL5WDAgD/mVgSvqfg6HxrwU3siPlq t3vQ== MIME-Version: 1.0 X-Received: by 10.112.181.232 with SMTP id dz8mr7776424lbc.8.1389533635517; Sun, 12 Jan 2014 05:33:55 -0800 (PST) Received: by 10.114.11.170 with HTTP; Sun, 12 Jan 2014 05:33:55 -0800 (PST) In-Reply-To: References: Date: Sun, 12 Jan 2014 08:33:55 -0500 Message-ID: Subject: Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities From: Jeff Trawick To: Apache HTTP Server Development List Content-Type: multipart/alternative; boundary=001a11c36c8abfa36404efc602a8 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c36c8abfa36404efc602a8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick 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/ --001a11c36c8abfa36404efc602a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <trawick@gmail.com> wrote:
Open source projects, ASF or otherwi= se, have varying procedures for commits of fixes to vulnerabilities. ...

I plan to update=A0http://httpd.apache.org/dev/guidelin= es.html=A0based on the outcome of the vote.

Fo= lks, if you want to express an opinion but haven't yet, please do so be= fore Tuesday.

I'll add something very close to the following, unl= ess the vote changes considerably:

---cut here---<= /div>
Open source projects, ASF or otherwise, have varying procedures = for commits of vulnerability fixes. =A0One important aspect of these proced= ures is whether or not fixes to vulnerabilities can be committed to a repos= itory with commit logs and possibly CHANGES entries which purposefully obsc= ure the vulnerability and omit any available vulnerability tracking informa= tion. =A0The Apache HTTP Server project has decided that it is in t= he best interest of our users that the initial commit of such code changes = to any branch will=A0provide the best description=A0availab= le=A0at that time as well as=A0any available tracking infor= mation such as CVE number when committing fixes for vulnerabilities to any = branch. =A0Committing of the fix will be delayed until the project determin= es 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, includi= ng 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 n= ot allow the general user community to determine if preventative measures s= hould be taken.
---cut here---

=A0
=A0One important aspect of these procedures is wheth= er or not fixes to vulnerabilities can be committed to a repository with co= mmit logs and possibly CHANGES entries which purposefully obscure the vulne= rability and omit any available vulnerability tracking information.

(The vulnerabilities I refer to are those wh= ich are not already announced or otherwise generally known to the user comm= unity, and where the would-be committer knows that a vulnerability is fixed= by the code change possibly being committed. =A0Often it will have been di= scussed 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 info= rmation when committing fixes for vulnerabilities to any branch.

[ ] It is mandatory to provide best available descript= ion and any available tracking information when committing fixes for vulner= abilities 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. =A0I think that the possible justification fo= r following the first choice for a particular fix is that the committer fee= ls that the vulnerability isn't severe enough to completely hide it but= it is severe enough that the vulnerability impact shouldn't be publici= zed until there is a proposed release with the fix which is being tested.




--
Born in Rosw= ell... married an alien...
http://emptyhammock.com/
--001a11c36c8abfa36404efc602a8--