geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Fri, 13 Feb 2009 20:46:59 GMT

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

View raw message