geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Fri, 13 Feb 2009 21:23:09 GMT

On Feb 13, 2009, at 3:46 PM, Joe Bohn wrote:

> 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).

I'm ok with saying we'll release "as fast as we can".

We don't have to pre-advertise a short vote... So, I don't think  
that's a big issue.

72 hours votes are an Apache guideline. It's not a hard-and-fast rule.  
The only *rules* are a simple majority of PMC +1 votes and a minimum  
of 3 PMC +1 votes. As long as the PMC feels that we have adequate and  
appropriate oversight, then I don't see an issue.

Assuming there is pre-vetting of releases, I'd hope that most votes  
will pass on the first RC.

>>> 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.

Any idea how other projects handle?


View raw message