geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Tue, 03 Feb 2009 19:26:49 GMT
Sounds good.


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 
>>>, full-disclosure at 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

View raw message