You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Donald Woods <dw...@apache.org> on 2009/01/19 15:14:02 UTC
[DISCUSS] Security Vulnerability Policy created
There was a long discussion around mid-December on the private and
security Geronimo mailing lists about how to handle security
vulnerabilities. The outcome of that discussion (which is mainly a
boilerplate suggested by Mark Thomas for all projects to use) can be
found on our Project Policies wiki page at -
http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
If you see anything that needs changing or information that needs to be
added, then please discuss on this thread.
Thanks,
Apache Geronimo PMC
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Donald Woods <dw...@apache.org>.
Agree. Looks like we're ready to update the wiki and then request one
last round of reviews to a broader group of people.
-Donald
Kevan Miller wrote:
> I've moved this back to the dev@. This is the danger of cross-posting.
> The reply-to for your original message (at least the one that I
> received) was user@. This DISCUSS belongs on dev@
>
>
> On Jan 19, 2009, at 5:10 PM, Donald Woods wrote:
>
>> Sounds good to me.
>>
>> Should step #8 include a post to the private@ list, so other PMC
>> members will have some history behind the fixes being checked into svn
>> in step #9?
>
> I like it. 8 is probably a good place to coordinate with the PMC.
>
> --kevan
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
I've moved this back to the dev@. This is the danger of cross-posting.
The reply-to for your original message (at least the one that I
received) was user@. This DISCUSS belongs on dev@
On Jan 19, 2009, at 5:10 PM, Donald Woods wrote:
> Sounds good to me.
>
> Should step #8 include a post to the private@ list, so other PMC
> members will have some history behind the fixes being checked into
> svn in step #9?
I like it. 8 is probably a good place to coordinate with the PMC.
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Donald Woods <dw...@apache.org>.
Sounds good to me.
Should step #8 include a post to the private@ list, so other PMC members
will have some history behind the fixes being checked into svn in step #9?
-Donald
Kevan Miller wrote:
>
> On Jan 19, 2009, at 9:14 AM, Donald Woods wrote:
>
>> There was a long discussion around mid-December on the private and
>> security Geronimo mailing lists about how to handle security
>> vulnerabilities. The outcome of that discussion (which is mainly a
>> boilerplate suggested by Mark Thomas for all projects to use) can be
>> found on our Project Policies wiki page at -
>> http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
>>
>> If you see anything that needs changing or information that needs to
>> be added, then please discuss on this thread.
>
> The only question I had concerned step 6. Should the fix be discussed on
> security@ and/or private@? It needs to be on a "private" list, to
> properly embargo the vulnerability until a fix is available. Since most
> of the discussions of the issue occur on security@geronimo, I think
> discussion of the fix is most appropriate there.
>
> Thoughts?
>
> --kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 19, 2009, at 9:14 AM, Donald Woods wrote:
> There was a long discussion around mid-December on the private and
> security Geronimo mailing lists about how to handle security
> vulnerabilities. The outcome of that discussion (which is mainly a
> boilerplate suggested by Mark Thomas for all projects to use) can be
> found on our Project Policies wiki page at -
> http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
>
> If you see anything that needs changing or information that needs to
> be added, then please discuss on this thread.
The only question I had concerned step 6. Should the fix be discussed
on security@ and/or private@? It needs to be on a "private" list, to
properly embargo the vulnerability until a fix is available. Since
most of the discussions of the issue occur on security@geronimo, I
think discussion of the fix is most appropriate there.
Thoughts?
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by David Jencks <da...@yahoo.com>.
On Feb 3, 2009, at 11:20 AM, Joe Bohn wrote:
> Donald Woods wrote:
>> Sounds good. I was assuming the SNAPSHOT build in #10 would be
>> handled by Jarek's automated builds and we would just say "yyyymmdd
>> or later SNAPSHOT build" and include the URL to our published
>> snapshot builds.
>
> Thanks Donald - I agree with using the automated build snapshots for
> the announce.
>
> So, is everybody OK with announcing vulnerabilities basically at the
> same time we create the JIRA and check the code in (the modified
> steps I listed below)?
>
> We would not be able to reference a SNAPSHOT in the announcement
> until one of our regularly scheduled builds runs ... which would
> imply that the basic information on the vulnerability would be
> "public" in the JIRA and code for perhaps a few hours before the
> official announce. Official release(s) that contained the fix would
> be as soon as reasonably possible after the announcement - probably
> several days or so for a new maintenance release on a major release
> that is already out there. Any new major release(s) under
> development would continue on the original schedule.
I'm fine with this.
thanks
david jencks
>
>
> Joe
>
>
>> -Donald
>> Joe Bohn wrote:
>>>
>>> I think the key question is when we will announce the
>>> vulnerability (current #11).
>>>
>>> My preference would be that we create a JIRA for the issue so that
>>> it can be included in the release notes (#9 - either with or
>>> without the CVE referenced).
>>>
>>> But that (along with the code check-in) creates a chicken and egg
>>> scenario which exposes some information about the vulnerability
>>> prior to the announce (currently step #11). I'm wondering if we
>>> should just go ahead and announce as soon as the code is checked-
>>> in and we have a SNAPSHOT available for download. In the
>>> announcement we could reference any appropriate workarounds and
>>> the availability of the fix in the latest SNAPSHOTS so that users
>>> can take appropriate action. Updated steps might look something
>>> like this (picking up at step #8):
>>>
>>> 8. Reach an agreement for the fix, announcement and release
>>> schedule with the submitter.
>>> 9. Create a JIRA and commit the fix in all actively maintained
>>> releases.
>>> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq
>>> at securityfocus.com, full-disclosure at lists.grok.org.uk and
>>> project security pages) sighting workarounds and latest SNAPSHOT
>>> published.
>>> 11. Update the JIRA and svn log to include the CVE number.
>>> 12. Roll a release for each actively maintained branch (unreleased
>>> trunk can wait.)
>>>
>>> It's not optimal (would be much better to have a release in hand)
>>> but perhaps it is an appropriate compromise given that we can't
>>> prevent some information from going public when code is checked-in.
>>>
>>> Joe
>>>
>>> Kevan Miller wrote:
>>>>
>>>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>>>
>>>>>
>>>>>
>>>>> Joe Bohn wrote:
>>>>>> Is the omission of any discussion of a JIRA intentional? In
>>>>>> other words, is it expected that a JIRA will *not* be created
>>>>>> to document or track the code change and that CVE will be the
>>>>>> only documentation of the issue (and then only after a server
>>>>>> image has already been released by changing the commit log)?
>>>>>
>>>>> Good point. I believe we should create the JIRA as part of step
>>>>> #9.
>>>>
>>>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also
>>>> contain information regarding the vulnerability (including CVE,
>>>> etc).
>>>>
>>>>>
>>>>>
>>>>>> If we are not creating a JIRA, then this brings up a
>>>>>> documentation issue. Not announcing the issue until after a
>>>>>> server release also causes some doc issues.
>>>>>> - We typically use JIRAs to identify all changes within a
>>>>>> release.
>>>>>> - We include the list of JIRAs fixed and outstanding within the
>>>>>> RELEASE_NOTES for each server release.
>>>>>> - The RELEASE_NOTES are included in the server images so that
>>>>>> anyone downloading a server image can easily understand what
>>>>>> issues are resolved or still outstanding with that release.
>>>>>> - So typically JIRAs must be resolved before we create a
>>>>>> release candidate. The entire release (including the release
>>>>>> notes) is then validated during the vote for the release
>>>>>> candidate.
>>>>>> Security fixes are important, so it seems that they should be
>>>>>> mentioned in the release notes. I also understand the
>>>>>> sensitive nature of these issues and the possibility of
>>>>>> exploitation. However, it seems that the code check-in itself
>>>>>> already has the potential to make the exposure public for those
>>>>>> watching carefully.
>>>>>> One possible solution would be to announce the vulnerability
>>>>>> once we have a work-around available and/or a fix available in
>>>>>> a SNAPSHOT image.
>>>>>
>>>>> Agree that we need to be as open as possible. As part of step
>>>>> #9, I'd like to see us add a reference to the fix (but not the
>>>>> complete details) on our Security pages for each release. Step
>>>>> #12 would also be updated, to go back and add the CVE number and
>>>>> more details to the Security pages as each branch is released.
>>>>
>>>> OK. Is it necessary to hide the CVE until 12? If so, I guess the
>>>> RELEASE_NOTES shouldn't include the CVE...
>>>>
>>>> --kevan
>>>>
>>>>
>>>
>>>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 13, 2009, at 3:46 PM, Joe Bohn wrote:
>
> Thanks for the quick response Kevan.
>
> Kevan Miller wrote:
>> Hi Joe,
>> Good questions.
>> On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
>>>
>>> I have a few practical questions:
>>> 1) Must all affected releases be released before we can announce?
>> IMO, no. But I think users must have a reasonable upgrade path to
>> receive the fix. A 2.0.x user could be reasonably expected to
>> upgrade to 2.1.x to receive the fix. However, I couldn't reasonably
>> expect a 2.1.x user to downgrade to 2.0.x to receive a fix. I
>> believe that Tomcat will sometimes delayed releases with security
>> fixes on their older releases.
>
> I like the emphasis on a reasonable upgrade path. So, based on your
> proposal and most recent input, would it be more correct to state
> step 10 as:
>
> 10. Roll a release for the most current actively maintained branch.
> Earlier maintained branches can wait assuming that there is a
> reasonable upgrade path to the most current actively maintained
> branch. Any unreleased trunk or branch must include the security
> fix but can proceed on current plans without any particular urgency
> regarding the delivery of the security fix.
>
>>>
>>> 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.
>> It is unbounded. I'd set a target of 36 hours.
>
> I don't see how this is possible. We have a 72 hour time-frame for
> any release vote and attempting to shorten that would just telegraph
> that there is a security issue. In addition, there is some
> substantial work and validation necessary to generate a release
> candidate prior to the vote (even assuming a last minute check-in of
> the security fix). I think a more reasonable target (assuming a
> flawless release and vote) would be 5 days (120 hours).
I'm ok with saying we'll release "as fast as we can".
We don't have to pre-advertise a short vote... So, I don't think
that's a big issue.
72 hours votes are an Apache guideline. It's not a hard-and-fast rule.
The only *rules* are a simple majority of PMC +1 votes and a minimum
of 3 PMC +1 votes. As long as the PMC feels that we have adequate and
appropriate oversight, then I don't see an issue.
Assuming there is pre-vetting of releases, I'd hope that most votes
will pass on the first RC.
>
>>>
>>> 3) Is it acceptable that the release notes will not include any
>>> reference of the security vulnerabilities which are resolved?
>> IMO, yes.
>
> I think this is a problem and will unnecessarily confuse our users.
Any idea how other projects handle?
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
Thanks for the quick response Kevan.
Kevan Miller wrote:
> Hi Joe,
> Good questions.
>
> On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
>
>>
>> I have a few practical questions:
>> 1) Must all affected releases be released before we can announce?
>
> IMO, no. But I think users must have a reasonable upgrade path to
> receive the fix. A 2.0.x user could be reasonably expected to upgrade to
> 2.1.x to receive the fix. However, I couldn't reasonably expect a 2.1.x
> user to downgrade to 2.0.x to receive a fix. I believe that Tomcat will
> sometimes delayed releases with security fixes on their older releases.
I like the emphasis on a reasonable upgrade path. So, based on your
proposal and most recent input, would it be more correct to state step
10 as:
10. Roll a release for the most current actively maintained branch.
Earlier maintained branches can wait assuming that there is a reasonable
upgrade path to the most current actively maintained branch. Any
unreleased trunk or branch must include the security fix but can proceed
on current plans without any particular urgency regarding the delivery
of the security fix.
>
>>
>> 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.
>
> It is unbounded. I'd set a target of 36 hours.
I don't see how this is possible. We have a 72 hour time-frame for any
release vote and attempting to shorten that would just telegraph that
there is a security issue. In addition, there is some substantial work
and validation necessary to generate a release candidate prior to the
vote (even assuming a last minute check-in of the security fix). I
think a more reasonable target (assuming a flawless release and vote)
would be 5 days (120 hours).
>
>>
>> 3) Is it acceptable that the release notes will not include any
>> reference of the security vulnerabilities which are resolved?
>
> IMO, yes.
I think this is a problem and will unnecessarily confuse our users.
>
>>
>> 4) Is it alright to update the commit log in a tag after a release has
>> been created?
>
> IMO, yes.
>
> --kevan
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
>
> I have a few practical questions:
> 1) Must all affected releases be released before we can announce?
IMO, no. But I think users must have a reasonable upgrade path to
receive the fix. A 2.0.x user could be reasonably expected to upgrade
to 2.1.x to receive the fix. However, I couldn't reasonably expect a
2.1.x user to downgrade to 2.0.x to receive a fix. I believe that
Tomcat will sometimes delayed releases with security fixes on their
older releases.
>
> 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.
It is unbounded. I'd set a target of 36 hours.
>
> 3) Is it acceptable that the release notes will not include any
> reference of the security vulnerabilities which are resolved?
IMO, yes.
>
> 4) Is it alright to update the commit log in a tag after a release
> has been created?
IMO, yes.
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
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
> <ma...@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
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 13, 2009, at 5:31 PM, Jarek Gawor wrote:
> On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller
> <ke...@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
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Jack Cai <gr...@gmail.com>.
>
>
> 8. Reach an agreement for the fix and announcement schedule with the
> submitter.
> 9. Announce the vulnerability (users, dev, security@a.o, 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.
>
How easy will we allow our users to fix the security issue by following the
instructions here? If it's something like "replace this jar with the
attached jar, and restart server" etc., then it looks easy. But if it's
something like "applying the fix committed in Revision XXXXXX, rebuild the
code and ...", then we are putting too much burden on users, assuming the
majority of our users never care to build Geronimo by themselves.
So in this sense, making a maintenance release is a preferrable "total"
solution for our users.
-Jack
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Feb 13, 2009 at 2:58 PM, Kevan Miller <ke...@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.)
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, security@a.o, 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
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
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, 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.
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
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.
Joe
Donald Woods wrote:
> Sounds good.
>
> -Donald
>
> Joe Bohn wrote:
>> Donald Woods wrote:
>>> Sounds good. I was assuming the SNAPSHOT build in #10 would be
>>> handled by Jarek's automated builds and we would just say "yyyymmdd
>>> or later SNAPSHOT build" and include the URL to our published
>>> snapshot builds.
>>
>> Thanks Donald - I agree with using the automated build snapshots for
>> the announce.
>>
>> So, is everybody OK with announcing vulnerabilities basically at the
>> same time we create the JIRA and check the code in (the modified steps
>> I listed below)?
>>
>> We would not be able to reference a SNAPSHOT in the announcement until
>> one of our regularly scheduled builds runs ... which would imply that
>> the basic information on the vulnerability would be "public" in the
>> JIRA and code for perhaps a few hours before the official announce.
>> Official release(s) that contained the fix would be as soon as
>> reasonably possible after the announcement - probably several days or
>> so for a new maintenance release on a major release that is already
>> out there. Any new major release(s) under development would continue
>> on the original schedule.
>>
>> Joe
>>
>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> Joe Bohn wrote:
>>>>
>>>> I think the key question is when we will announce the vulnerability
>>>> (current #11).
>>>>
>>>> My preference would be that we create a JIRA for the issue so that
>>>> it can be included in the release notes (#9 - either with or without
>>>> the CVE referenced).
>>>>
>>>> But that (along with the code check-in) creates a chicken and egg
>>>> scenario which exposes some information about the vulnerability
>>>> prior to the announce (currently step #11). I'm wondering if we
>>>> should just go ahead and announce as soon as the code is checked-in
>>>> and we have a SNAPSHOT available for download. In the announcement
>>>> we could reference any appropriate workarounds and the availability
>>>> of the fix in the latest SNAPSHOTS so that users can take
>>>> appropriate action. Updated steps might look something like this
>>>> (picking up at step #8):
>>>>
>>>> 8. Reach an agreement for the fix, announcement and release schedule
>>>> with the submitter.
>>>> 9. Create a JIRA and commit the fix in all actively maintained
>>>> releases.
>>>> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq at
>>>> securityfocus.com, full-disclosure at lists.grok.org.uk and project
>>>> security pages) sighting workarounds and latest SNAPSHOT published.
>>>> 11. Update the JIRA and svn log to include the CVE number.
>>>> 12. Roll a release for each actively maintained branch (unreleased
>>>> trunk can wait.)
>>>>
>>>> It's not optimal (would be much better to have a release in hand)
>>>> but perhaps it is an appropriate compromise given that we can't
>>>> prevent some information from going public when code is checked-in.
>>>>
>>>> Joe
>>>>
>>>> Kevan Miller wrote:
>>>>>
>>>>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Joe Bohn wrote:
>>>>>>> Is the omission of any discussion of a JIRA intentional? In
>>>>>>> other words, is it expected that a JIRA will *not* be created to
>>>>>>> document or track the code change and that CVE will be the only
>>>>>>> documentation of the issue (and then only after a server image
>>>>>>> has already been released by changing the commit log)?
>>>>>>
>>>>>> Good point. I believe we should create the JIRA as part of step #9.
>>>>>
>>>>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also
>>>>> contain information regarding the vulnerability (including CVE, etc).
>>>>>
>>>>>>
>>>>>>
>>>>>>> If we are not creating a JIRA, then this brings up a
>>>>>>> documentation issue. Not announcing the issue until after a
>>>>>>> server release also causes some doc issues.
>>>>>>> - We typically use JIRAs to identify all changes within a release.
>>>>>>> - We include the list of JIRAs fixed and outstanding within the
>>>>>>> RELEASE_NOTES for each server release.
>>>>>>> - The RELEASE_NOTES are included in the server images so that
>>>>>>> anyone downloading a server image can easily understand what
>>>>>>> issues are resolved or still outstanding with that release.
>>>>>>> - So typically JIRAs must be resolved before we create a release
>>>>>>> candidate. The entire release (including the release notes) is
>>>>>>> then validated during the vote for the release candidate.
>>>>>>> Security fixes are important, so it seems that they should be
>>>>>>> mentioned in the release notes. I also understand the sensitive
>>>>>>> nature of these issues and the possibility of exploitation.
>>>>>>> However, it seems that the code check-in itself already has the
>>>>>>> potential to make the exposure public for those watching carefully.
>>>>>>> One possible solution would be to announce the vulnerability once
>>>>>>> we have a work-around available and/or a fix available in a
>>>>>>> SNAPSHOT image.
>>>>>>
>>>>>> Agree that we need to be as open as possible. As part of step #9,
>>>>>> I'd like to see us add a reference to the fix (but not the
>>>>>> complete details) on our Security pages for each release. Step
>>>>>> #12 would also be updated, to go back and add the CVE number and
>>>>>> more details to the Security pages as each branch is released.
>>>>>
>>>>> OK. Is it necessary to hide the CVE until 12? If so, I guess the
>>>>> RELEASE_NOTES shouldn't include the CVE...
>>>>>
>>>>> --kevan
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Donald Woods <dw...@apache.org>.
Sounds good.
-Donald
Joe Bohn wrote:
> Donald Woods wrote:
>> Sounds good. I was assuming the SNAPSHOT build in #10 would be
>> handled by Jarek's automated builds and we would just say "yyyymmdd or
>> later SNAPSHOT build" and include the URL to our published snapshot
>> builds.
>
> Thanks Donald - I agree with using the automated build snapshots for the
> announce.
>
> So, is everybody OK with announcing vulnerabilities basically at the
> same time we create the JIRA and check the code in (the modified steps I
> listed below)?
>
> We would not be able to reference a SNAPSHOT in the announcement until
> one of our regularly scheduled builds runs ... which would imply that
> the basic information on the vulnerability would be "public" in the JIRA
> and code for perhaps a few hours before the official announce. Official
> release(s) that contained the fix would be as soon as reasonably
> possible after the announcement - probably several days or so for a new
> maintenance release on a major release that is already out there. Any
> new major release(s) under development would continue on the original
> schedule.
>
> Joe
>
>
>>
>>
>> -Donald
>>
>>
>> Joe Bohn wrote:
>>>
>>> I think the key question is when we will announce the vulnerability
>>> (current #11).
>>>
>>> My preference would be that we create a JIRA for the issue so that it
>>> can be included in the release notes (#9 - either with or without the
>>> CVE referenced).
>>>
>>> But that (along with the code check-in) creates a chicken and egg
>>> scenario which exposes some information about the vulnerability prior
>>> to the announce (currently step #11). I'm wondering if we should
>>> just go ahead and announce as soon as the code is checked-in and we
>>> have a SNAPSHOT available for download. In the announcement we could
>>> reference any appropriate workarounds and the availability of the fix
>>> in the latest SNAPSHOTS so that users can take appropriate action.
>>> Updated steps might look something like this (picking up at step #8):
>>>
>>> 8. Reach an agreement for the fix, announcement and release schedule
>>> with the submitter.
>>> 9. Create a JIRA and commit the fix in all actively maintained releases.
>>> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq at
>>> securityfocus.com, full-disclosure at lists.grok.org.uk and project
>>> security pages) sighting workarounds and latest SNAPSHOT published.
>>> 11. Update the JIRA and svn log to include the CVE number.
>>> 12. Roll a release for each actively maintained branch (unreleased
>>> trunk can wait.)
>>>
>>> It's not optimal (would be much better to have a release in hand) but
>>> perhaps it is an appropriate compromise given that we can't prevent
>>> some information from going public when code is checked-in.
>>>
>>> Joe
>>>
>>> Kevan Miller wrote:
>>>>
>>>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>>>
>>>>>
>>>>>
>>>>> Joe Bohn wrote:
>>>>>> Is the omission of any discussion of a JIRA intentional? In other
>>>>>> words, is it expected that a JIRA will *not* be created to
>>>>>> document or track the code change and that CVE will be the only
>>>>>> documentation of the issue (and then only after a server image has
>>>>>> already been released by changing the commit log)?
>>>>>
>>>>> Good point. I believe we should create the JIRA as part of step #9.
>>>>
>>>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also
>>>> contain information regarding the vulnerability (including CVE, etc).
>>>>
>>>>>
>>>>>
>>>>>> If we are not creating a JIRA, then this brings up a documentation
>>>>>> issue. Not announcing the issue until after a server release also
>>>>>> causes some doc issues.
>>>>>> - We typically use JIRAs to identify all changes within a release.
>>>>>> - We include the list of JIRAs fixed and outstanding within the
>>>>>> RELEASE_NOTES for each server release.
>>>>>> - The RELEASE_NOTES are included in the server images so that
>>>>>> anyone downloading a server image can easily understand what
>>>>>> issues are resolved or still outstanding with that release.
>>>>>> - So typically JIRAs must be resolved before we create a release
>>>>>> candidate. The entire release (including the release notes) is
>>>>>> then validated during the vote for the release candidate.
>>>>>> Security fixes are important, so it seems that they should be
>>>>>> mentioned in the release notes. I also understand the sensitive
>>>>>> nature of these issues and the possibility of exploitation.
>>>>>> However, it seems that the code check-in itself already has the
>>>>>> potential to make the exposure public for those watching carefully.
>>>>>> One possible solution would be to announce the vulnerability once
>>>>>> we have a work-around available and/or a fix available in a
>>>>>> SNAPSHOT image.
>>>>>
>>>>> Agree that we need to be as open as possible. As part of step #9,
>>>>> I'd like to see us add a reference to the fix (but not the complete
>>>>> details) on our Security pages for each release. Step #12 would
>>>>> also be updated, to go back and add the CVE number and more details
>>>>> to the Security pages as each branch is released.
>>>>
>>>> OK. Is it necessary to hide the CVE until 12? If so, I guess the
>>>> RELEASE_NOTES shouldn't include the CVE...
>>>>
>>>> --kevan
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
Donald Woods wrote:
> Sounds good. I was assuming the SNAPSHOT build in #10 would be handled
> by Jarek's automated builds and we would just say "yyyymmdd or later
> SNAPSHOT build" and include the URL to our published snapshot builds.
Thanks Donald - I agree with using the automated build snapshots for the
announce.
So, is everybody OK with announcing vulnerabilities basically at the
same time we create the JIRA and check the code in (the modified steps I
listed below)?
We would not be able to reference a SNAPSHOT in the announcement until
one of our regularly scheduled builds runs ... which would imply that
the basic information on the vulnerability would be "public" in the JIRA
and code for perhaps a few hours before the official announce. Official
release(s) that contained the fix would be as soon as reasonably
possible after the announcement - probably several days or so for a new
maintenance release on a major release that is already out there. Any
new major release(s) under development would continue on the original
schedule.
Joe
>
>
> -Donald
>
>
> Joe Bohn wrote:
>>
>> I think the key question is when we will announce the vulnerability
>> (current #11).
>>
>> My preference would be that we create a JIRA for the issue so that it
>> can be included in the release notes (#9 - either with or without the
>> CVE referenced).
>>
>> But that (along with the code check-in) creates a chicken and egg
>> scenario which exposes some information about the vulnerability prior
>> to the announce (currently step #11). I'm wondering if we should just
>> go ahead and announce as soon as the code is checked-in and we have a
>> SNAPSHOT available for download. In the announcement we could
>> reference any appropriate workarounds and the availability of the fix
>> in the latest SNAPSHOTS so that users can take appropriate action.
>> Updated steps might look something like this (picking up at step #8):
>>
>> 8. Reach an agreement for the fix, announcement and release schedule
>> with the submitter.
>> 9. Create a JIRA and commit the fix in all actively maintained releases.
>> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq at
>> securityfocus.com, full-disclosure at lists.grok.org.uk and project
>> security pages) sighting workarounds and latest SNAPSHOT published.
>> 11. Update the JIRA and svn log to include the CVE number.
>> 12. Roll a release for each actively maintained branch (unreleased
>> trunk can wait.)
>>
>> It's not optimal (would be much better to have a release in hand) but
>> perhaps it is an appropriate compromise given that we can't prevent
>> some information from going public when code is checked-in.
>>
>> Joe
>>
>> Kevan Miller wrote:
>>>
>>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>>
>>>>
>>>>
>>>> Joe Bohn wrote:
>>>>> Is the omission of any discussion of a JIRA intentional? In other
>>>>> words, is it expected that a JIRA will *not* be created to document
>>>>> or track the code change and that CVE will be the only
>>>>> documentation of the issue (and then only after a server image has
>>>>> already been released by changing the commit log)?
>>>>
>>>> Good point. I believe we should create the JIRA as part of step #9.
>>>
>>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also
>>> contain information regarding the vulnerability (including CVE, etc).
>>>
>>>>
>>>>
>>>>> If we are not creating a JIRA, then this brings up a documentation
>>>>> issue. Not announcing the issue until after a server release also
>>>>> causes some doc issues.
>>>>> - We typically use JIRAs to identify all changes within a release.
>>>>> - We include the list of JIRAs fixed and outstanding within the
>>>>> RELEASE_NOTES for each server release.
>>>>> - The RELEASE_NOTES are included in the server images so that
>>>>> anyone downloading a server image can easily understand what issues
>>>>> are resolved or still outstanding with that release.
>>>>> - So typically JIRAs must be resolved before we create a release
>>>>> candidate. The entire release (including the release notes) is
>>>>> then validated during the vote for the release candidate.
>>>>> Security fixes are important, so it seems that they should be
>>>>> mentioned in the release notes. I also understand the sensitive
>>>>> nature of these issues and the possibility of exploitation.
>>>>> However, it seems that the code check-in itself already has the
>>>>> potential to make the exposure public for those watching carefully.
>>>>> One possible solution would be to announce the vulnerability once
>>>>> we have a work-around available and/or a fix available in a
>>>>> SNAPSHOT image.
>>>>
>>>> Agree that we need to be as open as possible. As part of step #9,
>>>> I'd like to see us add a reference to the fix (but not the complete
>>>> details) on our Security pages for each release. Step #12 would
>>>> also be updated, to go back and add the CVE number and more details
>>>> to the Security pages as each branch is released.
>>>
>>> OK. Is it necessary to hide the CVE until 12? If so, I guess the
>>> RELEASE_NOTES shouldn't include the CVE...
>>>
>>> --kevan
>>>
>>>
>>
>>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Donald Woods <dw...@apache.org>.
Sounds good. I was assuming the SNAPSHOT build in #10 would be handled
by Jarek's automated builds and we would just say "yyyymmdd or later
SNAPSHOT build" and include the URL to our published snapshot builds.
-Donald
Joe Bohn wrote:
>
> I think the key question is when we will announce the vulnerability
> (current #11).
>
> My preference would be that we create a JIRA for the issue so that it
> can be included in the release notes (#9 - either with or without the
> CVE referenced).
>
> But that (along with the code check-in) creates a chicken and egg
> scenario which exposes some information about the vulnerability prior to
> the announce (currently step #11). I'm wondering if we should just go
> ahead and announce as soon as the code is checked-in and we have a
> SNAPSHOT available for download. In the announcement we could reference
> any appropriate workarounds and the availability of the fix in the
> latest SNAPSHOTS so that users can take appropriate action. Updated
> steps might look something like this (picking up at step #8):
>
> 8. Reach an agreement for the fix, announcement and release schedule
> with the submitter.
> 9. Create a JIRA and commit the fix in all actively maintained releases.
> 10. Announce the vulnerability (users, dev, security@a.o, bugtraq at
> securityfocus.com, full-disclosure at lists.grok.org.uk and project
> security pages) sighting workarounds and latest SNAPSHOT published.
> 11. Update the JIRA and svn log to include the CVE number.
> 12. Roll a release for each actively maintained branch (unreleased trunk
> can wait.)
>
> It's not optimal (would be much better to have a release in hand) but
> perhaps it is an appropriate compromise given that we can't prevent some
> information from going public when code is checked-in.
>
> Joe
>
> Kevan Miller wrote:
>>
>> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>>
>>>
>>>
>>> Joe Bohn wrote:
>>>> Is the omission of any discussion of a JIRA intentional? In other
>>>> words, is it expected that a JIRA will *not* be created to document
>>>> or track the code change and that CVE will be the only documentation
>>>> of the issue (and then only after a server image has already been
>>>> released by changing the commit log)?
>>>
>>> Good point. I believe we should create the JIRA as part of step #9.
>>
>> OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain
>> information regarding the vulnerability (including CVE, etc).
>>
>>>
>>>
>>>> If we are not creating a JIRA, then this brings up a documentation
>>>> issue. Not announcing the issue until after a server release also
>>>> causes some doc issues.
>>>> - We typically use JIRAs to identify all changes within a release.
>>>> - We include the list of JIRAs fixed and outstanding within the
>>>> RELEASE_NOTES for each server release.
>>>> - The RELEASE_NOTES are included in the server images so that anyone
>>>> downloading a server image can easily understand what issues are
>>>> resolved or still outstanding with that release.
>>>> - So typically JIRAs must be resolved before we create a release
>>>> candidate. The entire release (including the release notes) is then
>>>> validated during the vote for the release candidate.
>>>> Security fixes are important, so it seems that they should be
>>>> mentioned in the release notes. I also understand the sensitive
>>>> nature of these issues and the possibility of exploitation.
>>>> However, it seems that the code check-in itself already has the
>>>> potential to make the exposure public for those watching carefully.
>>>> One possible solution would be to announce the vulnerability once we
>>>> have a work-around available and/or a fix available in a SNAPSHOT
>>>> image.
>>>
>>> Agree that we need to be as open as possible. As part of step #9,
>>> I'd like to see us add a reference to the fix (but not the complete
>>> details) on our Security pages for each release. Step #12 would also
>>> be updated, to go back and add the CVE number and more details to the
>>> Security pages as each branch is released.
>>
>> OK. Is it necessary to hide the CVE until 12? If so, I guess the
>> RELEASE_NOTES shouldn't include the CVE...
>>
>> --kevan
>>
>>
>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
I think the key question is when we will announce the vulnerability
(current #11).
My preference would be that we create a JIRA for the issue so that it
can be included in the release notes (#9 - either with or without the
CVE referenced).
But that (along with the code check-in) creates a chicken and egg
scenario which exposes some information about the vulnerability prior to
the announce (currently step #11). I'm wondering if we should just go
ahead and announce as soon as the code is checked-in and we have a
SNAPSHOT available for download. In the announcement we could reference
any appropriate workarounds and the availability of the fix in the
latest SNAPSHOTS so that users can take appropriate action. Updated
steps might look something like this (picking up at step #8):
8. Reach an agreement for the fix, announcement and release schedule
with the submitter.
9. Create a JIRA and commit the fix in all actively maintained releases.
10. Announce the vulnerability (users, dev, security@a.o, bugtraq at
securityfocus.com, full-disclosure at lists.grok.org.uk and project
security pages) sighting workarounds and latest SNAPSHOT published.
11. Update the JIRA and svn log to include the CVE number.
12. Roll a release for each actively maintained branch (unreleased trunk
can wait.)
It's not optimal (would be much better to have a release in hand) but
perhaps it is an appropriate compromise given that we can't prevent some
information from going public when code is checked-in.
Joe
Kevan Miller wrote:
>
> On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>
>>
>>
>> Joe Bohn wrote:
>>> Is the omission of any discussion of a JIRA intentional? In other
>>> words, is it expected that a JIRA will *not* be created to document
>>> or track the code change and that CVE will be the only documentation
>>> of the issue (and then only after a server image has already been
>>> released by changing the commit log)?
>>
>> Good point. I believe we should create the JIRA as part of step #9.
>
> OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain
> information regarding the vulnerability (including CVE, etc).
>
>>
>>
>>> If we are not creating a JIRA, then this brings up a documentation
>>> issue. Not announcing the issue until after a server release also
>>> causes some doc issues.
>>> - We typically use JIRAs to identify all changes within a release.
>>> - We include the list of JIRAs fixed and outstanding within the
>>> RELEASE_NOTES for each server release.
>>> - The RELEASE_NOTES are included in the server images so that anyone
>>> downloading a server image can easily understand what issues are
>>> resolved or still outstanding with that release.
>>> - So typically JIRAs must be resolved before we create a release
>>> candidate. The entire release (including the release notes) is then
>>> validated during the vote for the release candidate.
>>> Security fixes are important, so it seems that they should be
>>> mentioned in the release notes. I also understand the sensitive
>>> nature of these issues and the possibility of exploitation. However,
>>> it seems that the code check-in itself already has the potential to
>>> make the exposure public for those watching carefully.
>>> One possible solution would be to announce the vulnerability once we
>>> have a work-around available and/or a fix available in a SNAPSHOT image.
>>
>> Agree that we need to be as open as possible. As part of step #9, I'd
>> like to see us add a reference to the fix (but not the complete
>> details) on our Security pages for each release. Step #12 would also
>> be updated, to go back and add the CVE number and more details to the
>> Security pages as each branch is released.
>
> OK. Is it necessary to hide the CVE until 12? If so, I guess the
> RELEASE_NOTES shouldn't include the CVE...
>
> --kevan
>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 19, 2009, at 12:32 PM, Donald Woods wrote:
>
>
> Joe Bohn wrote:
>> Is the omission of any discussion of a JIRA intentional? In other
>> words, is it expected that a JIRA will *not* be created to document
>> or track the code change and that CVE will be the only
>> documentation of the issue (and then only after a server image has
>> already been released by changing the commit log)?
>
> Good point. I believe we should create the JIRA as part of step #9.
OK. That sounds good. I'm assuming the RELEASE_NOTES will also contain
information regarding the vulnerability (including CVE, etc).
>
>
>> If we are not creating a JIRA, then this brings up a documentation
>> issue. Not announcing the issue until after a server release also
>> causes some doc issues.
>> - We typically use JIRAs to identify all changes within a release.
>> - We include the list of JIRAs fixed and outstanding within the
>> RELEASE_NOTES for each server release.
>> - The RELEASE_NOTES are included in the server images so that
>> anyone downloading a server image can easily understand what issues
>> are resolved or still outstanding with that release.
>> - So typically JIRAs must be resolved before we create a release
>> candidate. The entire release (including the release notes) is
>> then validated during the vote for the release candidate.
>> Security fixes are important, so it seems that they should be
>> mentioned in the release notes. I also understand the sensitive
>> nature of these issues and the possibility of exploitation.
>> However, it seems that the code check-in itself already has the
>> potential to make the exposure public for those watching carefully.
>> One possible solution would be to announce the vulnerability once
>> we have a work-around available and/or a fix available in a
>> SNAPSHOT image.
>
> Agree that we need to be as open as possible. As part of step #9,
> I'd like to see us add a reference to the fix (but not the complete
> details) on our Security pages for each release. Step #12 would
> also be updated, to go back and add the CVE number and more details
> to the Security pages as each branch is released.
OK. Is it necessary to hide the CVE until 12? If so, I guess the
RELEASE_NOTES shouldn't include the CVE...
--kevan
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Donald Woods <dw...@apache.org>.
Joe Bohn wrote:
> Is the omission of any discussion of a JIRA intentional? In other
> words, is it expected that a JIRA will *not* be created to document or
> track the code change and that CVE will be the only documentation of the
> issue (and then only after a server image has already been released by
> changing the commit log)?
Good point. I believe we should create the JIRA as part of step #9.
>
> If we are not creating a JIRA, then this brings up a documentation
> issue. Not announcing the issue until after a server release also
> causes some doc issues.
> - We typically use JIRAs to identify all changes within a release.
> - We include the list of JIRAs fixed and outstanding within the
> RELEASE_NOTES for each server release.
> - The RELEASE_NOTES are included in the server images so that anyone
> downloading a server image can easily understand what issues are
> resolved or still outstanding with that release.
> - So typically JIRAs must be resolved before we create a release
> candidate. The entire release (including the release notes) is then
> validated during the vote for the release candidate.
>
> Security fixes are important, so it seems that they should be mentioned
> in the release notes. I also understand the sensitive nature of these
> issues and the possibility of exploitation. However, it seems that the
> code check-in itself already has the potential to make the exposure
> public for those watching carefully.
>
> One possible solution would be to announce the vulnerability once we
> have a work-around available and/or a fix available in a SNAPSHOT image.
Agree that we need to be as open as possible. As part of step #9, I'd
like to see us add a reference to the fix (but not the complete details)
on our Security pages for each release. Step #12 would also be updated,
to go back and add the CVE number and more details to the Security pages
as each branch is released.
> This will substantially shorten the time between the code changes and
> announce, thereby limiting possible exposure from those noticing or
> discussing the purpose of code changes. I image that even innocent
> questions about changes which are being inserted to resolve security
> issues could result in an exposure becoming public in an ad hoc manner.
> Waiting to validate a full release after code check-in might increase
> the possibility that the exposure could be exploited. And what happens
> if there are other issues with the release that cause it to drag on
> longer than expected?
>
> However, a user can make an informed decision on how to proceed if we
> announce the resolution in a SNAPSHOT and they will get the information
> much more quickly. It will also allow the project to document the issue
> correctly in a formal release and address any other issues that arise in
> the release process.
>
> Joe
>
> Donald Woods wrote:
>> There was a long discussion around mid-December on the private and
>> security Geronimo mailing lists about how to handle security
>> vulnerabilities. The outcome of that discussion (which is mainly a
>> boilerplate suggested by Mark Thomas for all projects to use) can be
>> found on our Project Policies wiki page at -
>> http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
>>
>> If you see anything that needs changing or information that needs to
>> be added, then please discuss on this thread.
>>
>>
>> Thanks,
>> Apache Geronimo PMC
>>
>
>
Re: [DISCUSS] Security Vulnerability Policy created
Posted by Joe Bohn <jo...@earthlink.net>.
Is the omission of any discussion of a JIRA intentional? In other
words, is it expected that a JIRA will *not* be created to document or
track the code change and that CVE will be the only documentation of the
issue (and then only after a server image has already been released by
changing the commit log)?
If we are not creating a JIRA, then this brings up a documentation
issue. Not announcing the issue until after a server release also
causes some doc issues.
- We typically use JIRAs to identify all changes within a release.
- We include the list of JIRAs fixed and outstanding within the
RELEASE_NOTES for each server release.
- The RELEASE_NOTES are included in the server images so that anyone
downloading a server image can easily understand what issues are
resolved or still outstanding with that release.
- So typically JIRAs must be resolved before we create a release
candidate. The entire release (including the release notes) is then
validated during the vote for the release candidate.
Security fixes are important, so it seems that they should be mentioned
in the release notes. I also understand the sensitive nature of these
issues and the possibility of exploitation. However, it seems that the
code check-in itself already has the potential to make the exposure
public for those watching carefully.
One possible solution would be to announce the vulnerability once we
have a work-around available and/or a fix available in a SNAPSHOT image.
This will substantially shorten the time between the code changes and
announce, thereby limiting possible exposure from those noticing or
discussing the purpose of code changes. I image that even innocent
questions about changes which are being inserted to resolve security
issues could result in an exposure becoming public in an ad hoc manner.
Waiting to validate a full release after code check-in might increase
the possibility that the exposure could be exploited. And what happens
if there are other issues with the release that cause it to drag on
longer than expected?
However, a user can make an informed decision on how to proceed if we
announce the resolution in a SNAPSHOT and they will get the information
much more quickly. It will also allow the project to document the issue
correctly in a formal release and address any other issues that arise in
the release process.
Joe
Donald Woods wrote:
> There was a long discussion around mid-December on the private and
> security Geronimo mailing lists about how to handle security
> vulnerabilities. The outcome of that discussion (which is mainly a
> boilerplate suggested by Mark Thomas for all projects to use) can be
> found on our Project Policies wiki page at -
> http://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html
>
> If you see anything that needs changing or information that needs to be
> added, then please discuss on this thread.
>
>
> Thanks,
> Apache Geronimo PMC
>