On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller <firstname.lastname@example.org
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.)