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 [email protected] 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.
