incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eike Rathke <...@erack.de>
Subject Re: Population of ooo-security
Date Mon, 01 Aug 2011 18:04:43 GMT
Hi Rob,

On Saturday, 2011-07-30 17:41:28 -0400, Rob Weir wrote:

> > Regarding Apache OpenOffice.org, LibreOffice, Symphony, RedOffice,
> > NeoOffice, BrOffice, EuroOffice, etc. as siblings that share similar
> > code in their genes from the ancestor OpenOffice.org, this approach has
> > a shortcoming in collaboration.
> 
> The purpose of ooo-security is security.  Any other concerns,
> including collaboration with other projects, or even including
> collaboration within this project, are secondary.

I was referring collaboration on security, for the benefit of all.

> > Given that usually users / developers / security experts report
> > a problem to _their_ project's security team, this setup would mean
> > a one-way communication if that project decided to inform AOOo, actually
> > being a pre-notification in that direction. What is that project
> > expected to do from that point on? Wait until AOOo publishes the
> > disclosure and fix? I think the project would develop its own fix and,
> > hopefully, share it with AOOo (which would involve a CLA or a permissive
> > license or a grant) and also with other siblings.
> >
> 
> We've already discussed and generally agreed that we can pre-notify
> other related projects about vulnerabilities and fixes.  But
> pre-notification is not the same as saying that the other projects
> must be signed up to on ooo-security.

Well, my example was about pre-notification in the other direction, from
siblings to AOOo.

> > Now if siblings develop fixes independently because AOOo security runs
> > as a strict Apache closed coterie, we may get into the situation where
> > fixes are developed in parallel, maybe with different solutions or even
> > contradictory. I think the best would be if efforts would be bundled
> > instead and the best of all possible solutions shared as
> > pre-notification with siblings.
> >
> 
> There is nothing wrong with pre-notification.  That was my step #3 above.
> 
> Your example seems to be assuming that a single reporter reports the
> same flaw to OpenOffice, LibreOffice, Symphony, etc., independently,

No, my example was assuming that a single reporter reports only to one
project, which I think is the usual case. Further assumption was that
project would decide to pre-notify AOOo, knowing the same code is
affected.

> and that these projects develop patches independently.  I suspect that
> this occurrence is quite rare.  But I don't see that harm if it does
> happen.  The fact is these projects are not sharing code today,
> period.

Au contraire, you're right the projects aren't sharing code, in that
case a fix and update would be sufficient, but most projects still use
the same if not identical code in areas where security issues may be
discovered.

> This is not just a statement about security.  If we want to
> improve that situation with security specifically then we have two
> easy ways forward:
> 
> 1) Develop the patches at Apache under a license that allows all other
> products to use it
> 
> 2) Have security experts from LibreOffice developers join as Apache
> committers so they can then join the ooo-security list and contribute
> directly there.

An ideal situation I support. And btw, I wasn't talking of only
LibreOffice..


> > The problem here seems to be the perceived requirement that the Apache
> > governance would allow only PMC members on a project's security list.
> > However, I didn't see that requirement, or it's not available somewhere
> > under http://apache.org/security/
> >
> > Additionally http://apache.org/security/committers.html states that
> >
> > | Information may be shared with domain experts (eg colleagues at your
> > | employer) at the discretion of the project's security team providing
> > | that it is made clear that the information is not for public disclosure
> > | and that security@apache.org or the project's security mailing list must
> > | be copied on any communication regarding the vulnerability.
> >
> > This IMHO allows also to have selected members of sibling projects as
> > domain experts on the security list, if I interpret "at the discretion
> > of the project's security team" correctly.
> >
> 
> There is nothing there that talks about having these domain experts be
> list members.  In fact, it specifically talks about "copying"
> security@apache.org.  That would not be necessary if the domain
> experts were security list members, since all list project security
> traffic is copied automatically to security.apache.org as well.  Thus
> the information sharing implied here is through means other than
> subscription to the list.

To me it only sounds like that for any communication regarding the
vulnerability the project's (or apache) security list must be copied, so
information is shared when the domain expert communicates with a list
member and even if he consults another colleague. Of course the language
implies that the domain expert is not a list member, but "at the
discretion of the security team" is a degree of freedom to decide whom
to copy when, and if the team decides to get another expert on board on
a regular basis that's just fine.

> Also, if all traffic were automatically
> copied to 3rd party domain experts via their subscription to the list,
> then there would be zero discretion being exercised.

Given that only a hand full of known, respected and trusted persons
would be invited I don't see much difference whether they are Apache
committers or not, provided that the patches developed will be
contributed under AL2.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Mime
View raw message