On 12/11/2011 14:08, Rob Weir wrote:
On Sun, Dec 11, 2011 at 1:53 PM, TJ Frazier<[email protected]> wrote:
+1 in general; quibbles in-line.
On 12/11/2011 13:20, Rob Weir wrote:
I see that many other projects have an official announce list. This
would be used for official public communications:
1) New releases
2) New services
3) New blog posts
Unnecessary. Interested parties will track these themselves.
4) Security patches
Redundant. We should have a release ready with the fix, which will be
announced. --/tj/
Even with a release, we still should have a security announcement.
See step 14 here:
"The project team announces the release and the vulnerability.
Typically this will be sent to the reporter, the project's users list,
the project's dev list, the project's announce list,
[email protected], [email protected] and
[email protected]. The project's security pages should also be
updated. This is the first point that any information regarding the
vulnerability is made public."
http://www.apache.org/security/committers.html
So there is a summary of the vulnerability that gets posted to the
announce list, and several other lists, with a CVE number (Common
Vulnerabilities and Exposures). This makes it easy to cross reference
exactly what security issues are patches in a given release. Maybe
not so interesting for end users to have that detail broken out, but
it is important, for example, for those who repackage and redistribute
OpenOffice, e.g., Linux distros.
We might also be coordinating with other products or components on the
announcement. Say, hypothetically, that there is a horrible security
flaw in Hunspell. We'd coordinate with Hunspell, and with LO and
Firefox on a patch. We'd patch our tree and release a new AOO with
the fix. But we would coordinate the timing of the security
announcement until LO and Firefox also had their releases ready. You
don't want the first product that is released to "spill the beans" and
make the user's of the products that use the component vulnerable to a
now public issue. So there might be an interval between the release
announcement and the security announcement.
Good point, but ... if the code is in the release, then the source is in
SVN, which is as good as an announcement for some people. We may want to
coordinate releases, too; any delay should only be a matter of a few
days. I am underwhelmed by the thought of reading, "Oh, BTW, that latest
release fixes a horrid security bug, and you should install it ASAP ..."
/tj/
Note: this would be the exception to the rule that announcements are
pre-discussed by the PPMC. I'd expect that such announcements would
come directly from the security team. So we would need to have one of
the moderators for the announce list be from that team.
[snip]