geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Fri, 13 Feb 2009 16:47:08 GMT
Based on the positive feedback to my proposal I updated out wiki process 
document with the steps I proposed earlier.  See 
http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html for details.

Joe


Donald Woods wrote:
> Sounds good.
> 
> -Donald
> 
> 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.
>>
>> 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