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, [email protected]
<mailto:[email protected]>, 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
