From ooo-dev-return-6672-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Thu Oct 6 12:58:41 2011 Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6DCA87C94 for ; Thu, 6 Oct 2011 12:58:41 +0000 (UTC) Received: (qmail 96783 invoked by uid 500); 6 Oct 2011 12:58:41 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 96736 invoked by uid 500); 6 Oct 2011 12:58:41 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 96728 invoked by uid 99); 6 Oct 2011 12:58:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 12:58:41 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dirkx@webweaving.org designates 178.18.23.51 as permitted sender) Received: from [178.18.23.51] (HELO pikmeer.webweaving.org) (178.18.23.51) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2011 12:58:31 +0000 Received: from [192.168.1.100] ([132.185.237.144]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.4/8.14.4) with ESMTP id p96Cv3nC052595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Oct 2011 12:57:03 GMT (envelope-from dirkx@webweaving.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) Subject: Re: Vulnerability fixed in LibreOffice From: Dirk-Willem van Gulik In-Reply-To: <4E8D9D99.9010506@documentfoundation.org> Date: Thu, 6 Oct 2011 14:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <512F975D-682E-4EFF-A36C-CAA930AFBDE7@webweaving.org> References: <00e601cc8396$a4eeaca0$eecc05e0$@apache.org> <6AA74BAB-B366-4B88-9472-D78FA94DD599@webmink.com> <00ed01cc839c$70bd9030$5238b090$@apache.org> <4E001CA5-762B-4C3B-BF51-FC0BD26C06F8@comcast.net> <012601cc83b6$22112fe0$66338fa0$@acm.org> <4E8D959C.1010009@documentfoundation.org> <1698C6FB-5815-4CB1-903E-1507C82A8300@webweaving.org> <4E8D9D99.9010506@documentfoundation.org> To: ooo-dev@incubator.apache.org X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (pikmeer.webweaving.org [178.18.23.51]); Thu, 06 Oct 2011 12:57:03 +0000 (UTC) X-Virus-Checked: Checked by ClamAV on apache.org On 6 Oct 2011, at 13:22, Florian Effenberger wrote: > Dirk-Willem van Gulik wrote on 2011-10-06 14:14: >> 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. >=20 > for years, there has been security@ooo. That group knows each other = very well, has been working together in trust for many years, and not = only I proposed here on this list to continue working the way it was = before, since security is an area where we can work together closely = apart from any "political" issues. Good. So you have an excellent starting point. And know that this type = of sharing is very common already. > However, I was told several times, that this is not desired Reading the exchanges - I think language was getting in the way of = things. As I tried to outline - there are a few aspects pertaining to = oversight which need to be met (by any foundation - and the US makes = some of that a lighter touch, than, say, the legal system of the = Netherlands would allow a 'stichting' or 'vereniging'). But beyond that = - there is freedom. I can easily imagine a group of committers doing initial follow and = triage around security@$project.apache.org - who have a very routine, = very trusted and deep relation with other security groups outside the = ASF and vice versa. And I'd expect that you'd quickly gravitate towards = joint advisories and similar when appropriate. If that means that an MoU = is needed - well that would be a first - but not something you should = reject out of hand. Meanwhile the ASF will always be responsible, accountable and needs to = show it is in full control of each and every bit which goes out as a = release - and we (mostly) do that by ingress control on our version = control system. So CLA's are important. And the board will expect that = the PMC maintains proper oversight.=20 It is such a key part of a release and our responsibility that one = cannot easily 'farm this out'. Dw=