incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Proposal: ooo-announce list
Date Sun, 11 Dec 2011 20:14:36 GMT
On Sun, Dec 11, 2011 at 2:43 PM, TJ Frazier <tjfrazier@cfl.rr.com> wrote:
> On 12/11/2011 14:08, Rob Weir wrote:
>>
>> On Sun, Dec 11, 2011 at 1:53 PM, TJ Frazier<tjfrazier@cfl.rr.com>  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,
>> security@apache.org, full-disclosure@lists.grok.org.uk and
>> bugtraq@securityfocus.com. 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

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.  The security team would patch stealthily,
and only update the SVN comment after release and announcement.  There
are various ways of making such check-ins non-obvious, none of which I
will describe here.

Of course, someone could be really clever and figure it out by looking
at all check-ins.  But they could also be very clever and find it by
reading the code.  Obviously we're not fixing undetectable problems.
We're fixing the ones that have been detected.  If one person has
detected a problem then so can another, regardless of what we do.  But
we don't need to make it easy for them.

> 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]
>
>

Mime
View raw message