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, secur...@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
