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
