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 Mon, 19 Jan 2009 17:32:31 GMT

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.

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

>  This will substantially shorten the time between the code changes and 
> announce, thereby limiting possible exposure from those noticing or 
> discussing the purpose of code changes.  I image that even innocent 
> questions about changes which are being inserted to resolve security 
> issues could result in an exposure becoming public in an ad hoc manner. 
>   Waiting to validate a full release after code check-in might increase 
> the possibility that the exposure could be exploited.  And what happens 
> if there are other issues with the release that cause it to drag on 
> longer than expected?
> However, a user can make an informed decision on how to proceed if we 
> announce the resolution in a SNAPSHOT and they will get the information 
> much more quickly.  It will also allow the project to document the issue 
> correctly in a formal release and address any other issues that arise in 
> the release process.
> Joe
> Donald Woods wrote:
>> There was a long discussion around mid-December on the private and 
>> security Geronimo mailing lists about how to handle security 
>> vulnerabilities.  The outcome of that discussion (which is mainly a 
>> boilerplate suggested by Mark Thomas for all projects to use) can be 
>> found on our Project Policies wiki page at -
>> If you see anything that needs changing or information that needs to 
>> be added, then please discuss on this thread.
>> Thanks,
>> Apache Geronimo PMC

View raw message