incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: Vulnerability fixed in LibreOffice
Date Thu, 06 Oct 2011 12:14:49 GMT

On 6 Oct 2011, at 12:48, Florian Effenberger wrote:

> J├╝rgen Schmidt wrote on 2011-10-06 13:18:

>> If a TDF or ASF list is secondary for me but i would volunteer to join this
>> mailing list to help on this topic in the future. But maybe we should try to
>> keep the existing and knownsecurityteam@openoffice.org  mailing list and I
>> see no reason why it shouldn't work. I think it is probably more a problem
>> of the people on this list and missing communication. I assume that people
>> on this list have now other priorities and are not so responsive which of
>> course is natural if they have a new job or moved into other projects ...

> from what I understood, we were told that things at Apache are "different". IMHO, there
is an Apache security list, but only a few selected people can be on it, and IMHO they have
to be Apache contributors.

I think you are jumping to conclusions a bit here. There is a lot of room to differ.

Some background first.

The ASF want to be able to always stand behind 'its' releases. Be able to take, or even claim,
full responsibility for it. This is fairly key to our ability to protect both individual contributors,
our (end) users and the actual body of IPR itself.

This implies that we need a certain level of corporate oversight. 

In the ASF we delegate this almost completely down to the individual PMC. And we totally expect
the community to manage who it wants on its PMC and how it operates. The PMC does however
have to demonstrate that there is sufficient oversight. This falls on the PMC as we cannot
in any legally meaningful way expect this from the wider (and often anonymous) community without
placing overly cumbersome participation hurdles.

Now releases, and by extension security, is a special aspect of oversight. 

The ASF basically wants to have complete provenance of every bit it 'ships' as to allow to
fully stand behind it. And it wants a clear path to the decision what we ship, when we ship
and indirectly have proof that we know what we ship through things like release notes and
what not. The community makes that decision with oversight of the PMC of the Board.

Security is a special aspect of this. 

Needed here is good solid tracking of known issues - and not loosing sight of them.  This
is why the ASF expects each PMC to have a known contact (e.g. security@...) for security issues
- and expects those PMCs to have active oversight over their security committee(s). We really
do not want to ship with known issues. Not just for reputational reasons - but also as this
may really weakens our ability to stand behind the code and protect our constituents, the
code base and the community at large in the light of claims.

Secondly - we acknowledge that we sometimes need to keep (security) issues confidential for
short periods of time - as to allow responsible disclosure; work with other products who may
also be affected and so on. We also acknowledge that there are entities which are a (lot!)
less likely to share issues with us if they had to do so in the open - or would defer/delay
informing us significantly.

So those are more or less the parameters within which one has to operate. 

A practical approach to accomplish this is to have a few committers; often PMC members -sit
on security@project - and have these people, trusted by the community, do triage, prepare
advisories and so on. And then as swiftly as possible move the issue to dev@ - and announce
the CVE widely.

However that is by no means the only model. If this community decides it wants to do differently
- great. We all may learn something!

Do note though that a CLA may still be practical for those on security@ - as early triage
responses in some cases may require the (quick) creation of IPR and subsequent entering of
that IPR into the ASF or disseminating that IPR. So having a (lot of) security@ members without
a CLA would be awkward. Secondly - whatever the process is for this security@ - the PMC would
be expected to demonstrate good oversight. As in order to safeguard our code in the future
we do need to sometimes allow for short periods of confidentiality.

Furthermore - there is nothing stopping you from having a knownsecurity@ group more focused
on security - and having this as your first (more public) port of call.

Hope this helps,

Dw.
Mime
View raw message