svn commit: r894099 - in /websites/staging/httpd/trunk/content: ./ dev/guidelines.html

[bu...@apache.org]

Author: buildbot
Date: Tue Jan 14 16:04:57 2014
New Revision: 894099

Log:
Staging update by buildbot for httpd

Modified:
    websites/staging/httpd/trunk/content/   (props changed)
    websites/staging/httpd/trunk/content/dev/guidelines.html

Propchange: websites/staging/httpd/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Jan 14 16:04:57 2014
@@ -1 +1 @@
-1555226
+1558087

Modified: websites/staging/httpd/trunk/content/dev/guidelines.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/guidelines.html (original)
+++ websites/staging/httpd/trunk/content/dev/guidelines.html Tue Jan 14 16:04:57 2014
@@ -396,6 +396,30 @@ the top of the file, insert other change
      (See util_mutex.h.)  Build-time setting DEFAULT_LOCKFILE is no longer
      respected; set DEFAULT_REL_RUNTIMEDIR instead.  [Jeff Trawick]
 ` </p>
+<h1 id="committing-security-fixes">Committing Security Fixes</h1>
+<p>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.</p>
+<p>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.</p>
+<p>If a vulnerability is partially disclosed by committing a fix before the
+bug is determined to be exploitable, the httpd security team will decide
+when to document the security implications and tracking number on a case
+by case basis.</p>
 <h1 id="patch">Patch Format</h1>
 <p>When a specific change to the software is proposed for discussion or voting
 on the mailing list, it should be presented in the form of input to the