geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Tue, 03 Feb 2009 19:27:26 GMT

On Feb 3, 2009, at 11:20 AM, Joe Bohn wrote:

> Donald Woods wrote:
>> Sounds good.  I was assuming the SNAPSHOT build in #10 would be  
>> handled by Jarek's automated builds and we would just say "yyyymmdd  
>> or later SNAPSHOT build" and include the URL to our published  
>> snapshot builds.
>
> Thanks Donald - I agree with using the automated build snapshots for  
> the announce.
>
> So, is everybody OK with announcing vulnerabilities basically at the  
> same time we create the JIRA and check the code in (the modified  
> steps I listed below)?
>
> We would not be able to reference a SNAPSHOT in the announcement  
> until one of our regularly scheduled builds runs ... which would  
> imply that the basic information on the vulnerability would be  
> "public" in the JIRA and code for perhaps a few hours before the  
> official announce.  Official release(s) that contained the fix would  
> be as soon as reasonably possible after the announcement - probably  
> several days or so for a new maintenance release on a major release  
> that is already out there.  Any new major release(s) under  
> development would continue on the original schedule.

I'm fine with this.

thanks
david jencks

>
>
> Joe
>
>
>> -Donald
>> Joe Bohn wrote:
>>>
>>> I think the key question is when we will announce the  
>>> vulnerability (current #11).
>>>
>>> My preference would be that we create a JIRA for the issue so that  
>>> it can be included in the release notes (#9 - either with or  
>>> without the CVE referenced).
>>>
>>> But that (along with the code check-in) creates a chicken and egg  
>>> scenario which exposes some information about the vulnerability  
>>> prior to the announce (currently step #11).  I'm wondering if we  
>>> should just go ahead and announce as soon as the code is checked- 
>>> in and we have a SNAPSHOT available for download.  In the  
>>> announcement we could reference any appropriate workarounds and  
>>> the availability of the fix in the latest SNAPSHOTS so that users  
>>> can take appropriate action.  Updated steps might look something  
>>> like this (picking up at step #8):
>>>
>>> 8. Reach an agreement for the fix, announcement and release  
>>> schedule with the submitter.
>>> 9. Create a JIRA and commit the fix in all actively maintained  
>>> releases.
>>> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq  
>>> at securityfocus.com, full-disclosure at lists.grok.org.uk and  
>>> project security pages) sighting workarounds and latest SNAPSHOT  
>>> published.
>>> 11. Update the JIRA and svn log to include the CVE number.
>>> 12. Roll a release for each actively maintained branch (unreleased  
>>> trunk can wait.)
>>>
>>> It's not optimal (would be much better to have a release in hand)  
>>> but perhaps it is an appropriate compromise given that we can't  
>>> prevent some information from going public when code is checked-in.
>>>
>>> Joe
>>>
>>> Kevan Miller wrote:
>>>>
>>>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>>>
>>>>>
>>>>>
>>>>> Joe Bohn wrote:
>>>>>> Is the omission of any discussion of a JIRA intentional?  In  
>>>>>> other words, is it expected that a JIRA will *not* be created  
>>>>>> to document or track the code change and that CVE will be the  
>>>>>> only documentation of the issue (and then only after a server  
>>>>>> image has already been released by changing the commit log)?
>>>>>
>>>>> Good point.  I believe we should create the JIRA as part of step  
>>>>> #9.
>>>>
>>>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also  
>>>> contain information regarding the vulnerability (including CVE,  
>>>> etc).
>>>>
>>>>>
>>>>>
>>>>>> If we are not creating a JIRA, then this brings up a  
>>>>>> documentation issue.  Not announcing the issue until after a  
>>>>>> server release also causes some doc issues.
>>>>>> - We typically use JIRAs to identify all changes within a  
>>>>>> release.
>>>>>> - We include the list of JIRAs fixed and outstanding within the 

>>>>>> RELEASE_NOTES for each server release.
>>>>>> - The RELEASE_NOTES are included in the server images so that  
>>>>>> anyone downloading a server image can easily understand what  
>>>>>> issues are resolved or still outstanding with that release.
>>>>>> - So typically JIRAs must be resolved before we create a  
>>>>>> release candidate.  The entire release (including the release  
>>>>>> notes) is then validated during the vote for the release  
>>>>>> candidate.
>>>>>> Security fixes are important, so it seems that they should be  
>>>>>> mentioned in the release notes.  I also understand the  
>>>>>> sensitive nature of these issues and the possibility of  
>>>>>> exploitation.  However, it seems that the code check-in itself  
>>>>>> already has the potential to make the exposure public for those 

>>>>>> watching carefully.
>>>>>> One possible solution would be to announce the vulnerability  
>>>>>> once we have a work-around available and/or a fix available in  
>>>>>> a SNAPSHOT image.
>>>>>
>>>>> Agree that we need to be as open as possible.  As part of step  
>>>>> #9, I'd like to see us add a reference to the fix (but not the  
>>>>> complete details) on our Security pages for each release.  Step  
>>>>> #12 would also be updated, to go back and add the CVE number and  
>>>>> more details to the Security pages as each branch is released.
>>>>
>>>> OK. Is it necessary to hide the CVE until 12? If so, I guess the  
>>>> RELEASE_NOTES shouldn't include the CVE...
>>>>
>>>> --kevan
>>>>
>>>>
>>>
>>>
>


Mime
View raw message