incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)
Date Thu, 12 Apr 2012 18:31:24 GMT
On 4/12/2012 2:59 AM, ant elder wrote:
> On Thu, Apr 12, 2012 at 8:37 AM, Ross Gardler
> <> wrote:
>> On 12 April 2012 07:48, Dave Fisher <> wrote:
>> ...
>>> Sorry, I can't remain mute, but I offended anyone, sorry, but this was wrongly
done. I don't know a better way....

Don't, these concerns can and should be aired.  Any deviation from the
usual ASF practices should be defended (and defensible) or they should be
discarded.  I don't think you are wrong to be disturbed by the process,
but I do expect most of the AOOo PPMC will find what actually transpired
was reasonable, under the circumstances, after you _all_ discuss it in
postmortem evaluation.  That's dev@ list business.

>> As one of the "inner circle" I am not offended. All your points are
>> valid. Thank you for sharing them.
>> This was the first and, in all likelihood the last time such an
>> unusual circumstance will arise. There is no right or wrong way of
>> handling these things.
>> Had we included x then y would have felt excluded, this is what we are
>> seeing here. However, the line must be drawn somewhere.
> Surely at the ASF the line is at PMC membership. If only a subset of
> the PPMC is trusted enough to be part of some inner circle then the
> PPMC should be disbanded and reformed from just that inner circle.
> Equally for the Incubator PMC, if Noel or who ever was chair should
> have been told then the Incubator PMC should have been included.

I'll refer to httpd, since it has the longest track record of security
incident handling.  There is about 1/4 of the httpd PMC who choose to be
active as part of the security list.  That group will go to the effort
to respond to reports, test reported defects, write patches, test patches
and help get the trunk or branch into some state that we can have a release.

If the incident is (or becomes) publicly known, the security@ list wipes
their hands of it, this mechanism is only used for embargoed issues.
There is sometimes a parallel discussion on security@ when a publicly
discussed flaw or patch has undisclosed security implications, but that's
pretty rare.

Well over half of the httpd PMC doesn't participate a whole lot in the
first place, including voting on release candidates, so expanding the
knowledge of undisclosed vulnerabilities to that group makes zero sense.
As a PMC member, any of them would be welcome to join the security team,
just as any can leave it if they don't have time or interest to follow
the security space.

I don't think we can compare the current AOOo situation; the "PMC" here
is effectively the IPMC, the only group of people with binding votes.
95% of that PMC should not have had advance knowledge of the specifics
of these defects, because 95% have little to do with AOOo on a daily
basis.  The people who would do the testing/verification/patch authoring
and further testing and verification needed to be on that list, but of
course are not binding PMC members [yet].  And of course there are even
meta security lists of lists in this case, owing to multiple projects
which are based on the common source code and subject to the same or very
similar defect exposures.

So the AOOo has assembled a hybrid model of some mentors and some of those
committed developers.  Certainly the project is going to refine policy going
forwards.  If I could do it over at httpd, I'd suggest anyone who has not
participated in the resolution of the past 'X' defects would be booted from
that security team.  [Gently nudged off might be more diplomatic.]  Perhaps
some combination of incidents and period of time.  security@ participation
is not some privilege, it's added responsibility to the PMC and project by
each of its subscribers.

But the point is that simply for issues of email transport compromise,
the people subscribed to that list need to pay extra attention to strictly
using ssl transport rather than plain text over public and private networks,
and that list needs to be broadcast to those people who will act on those
security emails, and to absolutely nobody else.

AOOo will continue to refine its practices in security@ handling, and I'd
trust them to make balanced and measured compromises from what I've observed
so far in my role on the ASF Security Team.  Upon becoming a TLP it will be
much easier to balance karma, authority and responsibility for security fixes,
and these will come much more organically from a then-shipping ASF package
which already had been released by the whole of the PMC.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message