Well, the Apache practice is clear. Putting a CVE number in a patch is probably not the way to execute on that practice, but that is not an Apache patch you are looking at.
Red Hat also has a very large list of CVEs that you can find in their issue tracker and elsewhere. I am not clear when and how those show up and I don't know what it means when such an issue is shown as unresolved, either. LibreOffice might want to take a page from the time-tested ASF Security procedures with regard to avoiding premature disclosure, etc. Having said that, we are all learning on the job with regard to security issues surrounding the OpenOffice.org family. As the product becomes a more-profitable target for culprits, I am certain that there will be more to learn. - Dennis PS: It might be nice to have a single public place to discuss just these practices across the family without deflecting the reporting lists from their focused purpose with regard to receiving and assessing vulnerability and exploit reports. Although I think one would be useful to have, there does not seem to be much interest on the part of the various security teams. -----Original Message----- From: Andrea Pescetti [mailto:[email protected]] Sent: Monday, December 12, 2011 07:14 To: [email protected] Subject: Re: Proposal: ooo-announce list On 11/12/2011 Rob Weir wrote: > Tthe practice is to check in such fixes without making it evident to > the observer that it is security-related. So don't expect SVN > comments to give it away. Like this? http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf5d0e20f2ba5a71f9ca2ed78a1b24841c97bb06 I know the example is from LibreOffice (even though the bug might be shared with OpenOffice.org or Apache OpenOffice) but I just happened to spot it and it doesn't seem particularly hidden... Such a policy would have to apply to all related projects (again, I totally don't know if this bug is related to Apache OpenOffice too, I'm just discussing the issue in general). Regards, Andrea.
