(See https://www.apache.org/security/committers for background)
For CVE-2013-4131 our process was: (v1) - Receive report - Come up with a fix - Gather 3 +1 votes via shadow status file - Commit fix with innocent log message - Backport without going via STATUS - Tag and roll 1.8.(x+1) - In parallel: + Gather release votes + Send pre-notifications - Release + announce publicly. Going forward, can we change the process to do the pre-notifications *before* committing the fix publicly (even if the log message doesn't describe the security implications)? That lets major vendors apply the patch before the issue is known to commits@ readers. I would guess that we'll want to have three +1s on the patch (gathered via private@ or via the shadow status file) before we announce it privately, so that it qualifies for the "ASF Release" legal umbrella. So, to be concrete, our process would be: (v2) - Receive report - Come up with a fix - Gather 3 +1 votes via shadow status file - Send pre-notifications - Commit fix with innocent log message - Backport normally (via STATUS) - Tag and roll 1.8.(x+1) - Gather release votes - Release + announce publicly. For completeness, here's a third alternative, which goes a step further towards eliminating security-by-obscurity from our process: (v3) - Receive report - Come up with a fix - Gather 3 +1 votes via shadow status file - Send pre-notifications - Release a signed .diff file (instead of a tarball) as 1.8.(x+1) - Commit fix with a log message clearly outlining the security implications - Backport without going via STATUS (already has 3 +1s) - Tag and roll 1.8.(x+2) whenever we had scheduled the next release to. Personally I think v3 is better than v2 (since it avoids security-by-obscurity) and v2 is better than our current process (for same reason). Daniel
