On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller <[email protected]> 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.
I'm not sure I agree with this. We should not need a new release for any security problem. We should be able to announce any vulnerability as long as we provide work-arounds (i.e. how to disable a component or whatever to prevent the security vulnerability from being exposed in the first place) or provide patches that fix the vulnerability (in binary, source or whatever format). For example, say we have some security problem in Axis2 plugin. In that case, we should be able to release new (fixed) Axis2 plugin and provide instructions on how to uninstall the old plugin and install the new one. In other cases we could just publish somewhere an updated jar file and tell people how to update it. This way we could create a new release at any point after the vulnerability was announced and be totally open when we commit fixes for the problem (i.e. reference CVE in log messages at the commit time and have CVE mentioned in the release notes, etc.) So in my opinion the process should be: 8. Reach an agreement for the fix and announcement schedule with the submitter. 9. Announce the vulnerability (users, dev, [email protected], bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk and project security pages). The vulnerability announcement must provide instructions on how to prevent or fix the security problem. 10. Create a JIRA and commit the fix in all actively maintained releases referencing the CVE number. and that's it. The only issue is that fix in step 8 is generated against latest official release (e.g. 2.0.2 or 2.1.3) but what gets committed to actively maintained branches might be slightly different (to account for other changes that might have been done in the branch). Jarek
