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
