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 Tue, 03 Feb 2009 19:20:18 GMT
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