Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4974B92F.7060502@apache.org>
Date: Mon, 19 Jan 2009 12:32:31 -0500
From: Donald Woods <dwoods@apache.org>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: [DISCUSS] Security Vulnerability Policy created
References: <49748AAA.6040009@apache.org> <4974B37A.6020004@earthlink.net>
In-Reply-To: <4974B37A.6020004@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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 -
>>   http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
>>
>> If you see anything that needs changing or information that needs to 
>> be added, then please discuss on this thread.
>>
>>
>> Thanks,
>> Apache Geronimo PMC
>>
> 
>