(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
Received on 2013-08-07 11:49:22 CEST