geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [DISCUSS] Security Vulnerability Policy created
Date Mon, 16 Feb 2009 14:27:11 GMT

On Feb 13, 2009, at 5:31 PM, Jarek Gawor wrote:

> On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller  
> <kevan.miller@gmail.com> 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.)

I'd thought about a "reasonable configuration work-around" clause or a  
plugin/jar release. Both are potentially valid options. However, I  
don't think they should be our preferred mode. IMO, our preferred mode  
should be a full Geronimo "release".

Configuration work-arounds typically disable some feature (so that  
users won't be exposed to a vulnerability). In cases where the  
vulnerability presents a high (or well-known) risk, I think a  
configuration work-around is a valid approach to quickly reducing the  
risk caused by the exposure.

A plugin/jar *release* could also work. As long as it is an official  
Geronimo project release. However, it seems less than desirable. There  
will be confusion about whether or not someone has installed the new  
plugin/jar, etc. I'd much prefer to see a full release.

A simple source code patch is not going to be acceptable to me --  
unless the project votes on the patch code and creates a "release".  
Simpler, I think to create a full release.

A full Geronimo server release is the easiest and least confusing  
means of delivering security updates to our users. It is the same  
technique used by multiple Apache projects. I think we can make it  
work for us, also.

--kevan
Mime
View raw message