What bureaucratic obstacles?
Simon Phipps wrote on Thu, Jul 28, 2011 at 15:01:38 -0700: > Another even simpler alternative would be to host the community > security list elsewhere where these bureaucratic obstacles do not > exist. I'd be happy to arrange that and ensure all of the relevant > parties are freely able to participate. If necessary the mailing list > here at Apache could then be subscribed to that list so that the > people willing and able to submit the Apache's processes are able to > participate and conduct their private discussions. > > S. > > On 28 Jul 2011, at 14:46, Rob Weir wrote: > > > Another really simple solution: > > > > One or two LO developers, say Caolan and one other, each return the > > iCLA and state that they would like to help us with security > > vulnerabilities response. Given that expressed commitment to the > > project, I would not hesitate to then nominate them and vote for them > > as committers. They then would get added to ooo-security. > > > > I think that gives you what you want, and it gives me what I want and > > what I understand Apache policy expects. Would something like that > > work? (Of course I have no idea if this is what Caolan wants). > > > > -Rob > > > > On Thu, Jul 28, 2011 at 5:25 PM, Rob Weir <[email protected]> wrote: > >> On Thu, Jul 28, 2011 at 4:04 PM, Dennis E. Hamilton <[email protected]> > >> wrote: > >>> I support Malte's recommendation to add two individuals that are > >>> currently in-common with respect to OpenOffice.org (traditional) and > >>> LibreOffice. > >>> > >> > >> If by "in common" you mean common to LibreOffice and the Apache > >> OpenOffice PPMC, then I'm fine with that. Otherwise -1, for the > >> reasons I previously stated. The ooo-security list is for management > >> of the security response, which is a project oversight responsibility. > >> It is not the exclusive avenue we have for collaboration on the > >> analysis or technical resolution. We should not be confusing these > >> two tasks. > >> > >> Note that along with my -1 I'm providing an alternative and expressing > >> my willingness to implement it, namely: > >> > >> 1) We gather a list of volunteer security experts, their names, email > >> address, perhaps cell phone numbers, as well as areas of expertise > >> > >> 2) We store this info in a text file in the PPMC's private directory > >> > >> 3) If the members of the ooo-security list determine that they need > >> expertise in a particular domain, on a particular problem, then they > >> can agree to consult with 3rd party experts. This would be done on a > >> case-by-case basis. > >> > >> 4) Such consultations would be done in accordance with the Apache > >> security policy, which requires that we cc [email protected] on any > >> such external communication > >> > >> -Rob > >> > >>> - Dennis > >>> > >>> MORE THOUGHTS > >>> > >>> Of the three of us moderating the ooo-security list, I believe only one > >>> of us has experience in these matters, and that is Malte. Malte who > >>> recommends accepting two subscribers who are also on the OOo-security > >>> list and the LibreOffice security list. One of them (Caolan) is known to > >>> me already. > >>> > >>> Also, when we were advised (twice) by security to do this, it was > >>> recommended that we find a way to cross-couple. > >>> > >>> I think it is important to establish this coverage in advance of a > >>> problem, since rapid, mutual assessment can be critical in the case of a > >>> critical exploit (and I have none in mind). > >>> > >> > >> I believe having a more comprehensive list of security experts would > >> help in having a rapid response. > >> > >>> Finally, we at Apache Oo.o are not the nexus here. At the moment we > >>> don't have a distro, we don't even have an issues mechanism, let alone a > >>> way to accept a patch. The odds are that anything in the current base is > >>> going to be acted on most adroitly by LibreOffice first, others if > >>> impacted, and then ourselves when we are in a position to issue > >>> remediated code. > >>> > >> > >> The problem might be in a 3rd party component. Maybe a 3rd party > >> component that we have (due to our replacement of LPGL components) > >> that LO does not have. I wouldn't assume in advance what the most > >> rapid way to respond to a report would be and what expertise would be > >> needed. > >> > >>> I for one would also welcome participation by security experts from other > >>> sources, including experts from IBM and Microsoft too. > >>> > >> > >> Depending on the specific issue I would welcome participation from > >> dozens of possible experts. But that does not mean that I want dozens > >> of experts on ooo-security. I think it just means that we keep a good > >> Rolodex of experts we can contact for any specific issue. > >> > >>> With regard to iCLAs, I don't think that is critical with regard to > >>> assessment and even discussion of remedies. It only matters when patches > >>> are prepared and it seems reasonable for that to be done by our own PPMC > >>> for our code base (when we have one). It might not serve other distros > >>> and implementations to rely on our patch, but in any case it is also > >>> appropriate to coordinate disclosure and remedy and not presume that > >>> everyone is downstream from us. > >>> > >> > >> One of key functions of ooo-security is to prepare the patch. So the > >> iCLA is relevant. > >> > >> I also think that the ooo-security, since it is working without > >> consultations from the entire PPMC, is acting as their agents, in > >> making decisions on the best oversight of the project in that specific > >> area. I think that should be entrusted to a group that has shown a > >> level of commitment to the project that is associated with being a > >> committer and a PMC member. > >> > >> Just so I'm clear, I see two functions: > >> > >> 1) Managing the response == ooo-security, representing the PPMC's > >> project oversight interests > >> > >> 2) Technical evaluation and rsolution == ooo-security + whatever > >> domain experts we bring in for a specific issue per Apache policy > >> > >> This is the approach that limits inadvertent and premature disclosure. > >> We should be keeping ooo-security as small as necessary to do the > >> response management task. > >> > >> I think my approach gives every benefit of your approach -- including > >> the ability to consult with whatever expert we want in order to > >> provide a rapid response -- without the liabilities of your approach. > >> > >>> > >>> -----Original Message----- > >>> From: Rob Weir [mailto:[email protected]] > >>> Sent: Wednesday, July 27, 2011 19:09 > >>> To: [email protected] > >>> Subject: Re: Population of ooo-security > >>> > >>> On Wed, Jul 27, 2011 at 9:23 PM, Dennis E. Hamilton <[email protected]> > >>> wrote: > >>>> Now that we've confirmed that the ooo-security list exists and the three > >>>> moderators appear to be subscribers, I believe the next action is to > >>>> subscribe the existing OO.o/LibreOffice security folk, per > >>>> > >>>> <http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%[email protected]%3e> > >>>> > >>> > >>> -1. This is the project's private security list, with only a subset > >>> of the PPMC on it. We should not have 3rd parties signed up on it. > >>> > >>> Observe the process here: > >>> > >>> http://www.apache.org/security/committers.html > >>> > >>> "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 [email protected] or the project's security > >>> mailing list must be copied on any communication regarding the > >>> vulnerability." > >>> > >>> So there is a distinction here between the "project's security team" > >>> and "domain experts". I'd like to see the ooo-security list be the > >>> former, and have us bring in the later when necessary for a particular > >>> issue. > >>> > >>> I think it would be a great idea to track, in a text file in the > >>> PPMC's private directory, a list of 3rd party experts who could be > >>> consulted for particular kinds of issues. But if and when to bring > >>> in those 3rd parties should be decided on a case by case basis. > >>> > >>>> There was also a notion of cross-subscribing some lists, but that would > >>>> probably be after that. > >>>> > >>> > >>> We could put those addresses into the private text file as well, but > >>> I'd rather trust an person's email address than to trust an opaque > >>> list. > >>> > >>> -Rob > >>> > >>>> - Dennis > >>>> > >>>> -----Original Message----- > >>>> From: Rob Weir [mailto:[email protected]] > >>>> Sent: Tuesday, July 26, 2011 13:33 > >>>> To: [email protected] > >>>> Subject: Testing > >>>> > >>>> This is a test, to see if the list has been set up properly. > >>>> > >>>> -Rob > >>>> > >>>> > >>> > >>> > >> >
