Thanks for the quick response Kevan.
Kevan Miller wrote:
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
I have a few practical questions:
1) Must all affected releases be released before we can announce?
IMO, no. But I think users must have a reasonable upgrade path to
receive the fix. A 2.0.x user could be reasonably expected to upgrade to
2.1.x to receive the fix. However, I couldn't reasonably expect a 2.1.x
user to downgrade to 2.0.x to receive a fix. I believe that Tomcat will
sometimes delayed releases with security fixes on their older releases.
I like the emphasis on a reasonable upgrade path. So, based on your
proposal and most recent input, would it be more correct to state step
10 as:
10. Roll a release for the most current actively maintained branch.
Earlier maintained branches can wait assuming that there is a reasonable
upgrade path to the most current actively maintained branch. Any
unreleased trunk or branch must include the security fix but can proceed
on current plans without any particular urgency regarding the delivery
of the security fix.
2) How long is considered too long between the check-in of code for
any release (which will likely divulge the vulnerability) and the
delivery of a release (or releases) which must precede the announce in
the steps above? It would seem that with this proposal the
time-period is unbounded.
It is unbounded. I'd set a target of 36 hours.
I don't see how this is possible. We have a 72 hour time-frame for any
release vote and attempting to shorten that would just telegraph that
there is a security issue. In addition, there is some substantial work
and validation necessary to generate a release candidate prior to the
vote (even assuming a last minute check-in of the security fix). I
think a more reasonable target (assuming a flawless release and vote)
would be 5 days (120 hours).
3) Is it acceptable that the release notes will not include any
reference of the security vulnerabilities which are resolved?
IMO, yes.
I think this is a problem and will unnecessarily confuse our users.
4) Is it alright to update the commit log in a tag after a release has
been created?
IMO, yes.
--kevan
