Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=XyBPWnr1iB4xuz48q6X4rpWfNqTG01bxibIfnPyjo3vhkv2AeluzrgxnbRGjEzJh;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <4995D46C.6000607@earthlink.net>
Date: Fri, 13 Feb 2009 15:13:32 -0500
From: Joe Bohn <joe.bohn@earthlink.net>
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>
 <4974B92F.7060502@apache.org>
 <1AE43487-AB1A-4A4E-A836-426C767D186C@gmail.com>
 <4975D3DB.9050600@earthlink.net> <4975F3BC.5080602@apache.org>
 <498898F2.9000806@earthlink.net> <49889A79.1090403@apache.org>
 <4995A40C.1070508@earthlink.net>
 <E855BA4B-8584-4C1F-B127-FBB7F1F07203@gmail.com>
In-Reply-To: <E855BA4B-8584-4C1F-B127-FBB7F1F07203@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kevan Miller wrote:
> 
> On Feb 13, 2009, at 11:47 AM, Joe Bohn wrote:
> 
>> 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.
> 
> Sorry, I thought that I'd replied to this, already.
> 
> I have one change -- a *release* (i.e. a release vote) must precede the 
> formal announcement of a vulnerability.
> 
> So, I would make the process:
> 
> 9. Create a JIRA and commit the fix in all actively maintained releases. 
> The contents of the Jira should not indicate that it is a 
> security-related Jira.
> 10. Roll a release for each actively maintained branch (unreleased trunk can wait.)
> 11. Announce the vulnerability (users, dev, security@a.o 
> <mailto:security@a.o>, bugtraq at securityfocus.com, full-disclosure at 
> lists.grok.org.uk and project security pages)
> 12. Update the JIRA and svn log with security-related information and 
> include the CVE number.
> 
> The svn commit at step 9 may contain enough information to indicate the 
> security vulnerability. However, until we have a *release*, we don't 
> have an Apache-sanctioned resolution to the problem. The voting process 
> for a security-fix release can be expedited (by pre-vetting the release 
> on private mailing lists). I'm comfortable with this slight exposure. 
> Also, this is the same basic process followed by other Apache projects. 

I have a few practical questions:
1) Must all affected releases be released before we can announce?
2) How long is considered too long between the check-in of code for any 
release (which will likely divulge the vulnerability) and the delivery 
of a release (or releases) which must precede the announce in the steps 
above?  It would seem that with this proposal the time-period is unbounded.
3) Is it acceptable that the release notes will not include any 
reference of the security vulnerabilities which are resolved?
4) Is it alright to update the commit log in a tag after a release has 
been created?

Thanks,
Joe