On 4/12/2012 2:59 AM, ant elder wrote: > On Thu, Apr 12, 2012 at 8:37 AM, Ross Gardler > <rgard...@opendirective.com> wrote: >> On 12 April 2012 07:48, Dave Fisher <dave2w...@comcast.net> wrote: >> >> ... >> >>> Sorry, I can't remain mute, but I offended anyone, sorry, but this was >>> wrongly done. I don't know a better way....
Don't, these concerns can and should be aired. Any deviation from the usual ASF practices should be defended (and defensible) or they should be discarded. I don't think you are wrong to be disturbed by the process, but I do expect most of the AOOo PPMC will find what actually transpired was reasonable, under the circumstances, after you _all_ discuss it in postmortem evaluation. That's dev@ list business. >> As one of the "inner circle" I am not offended. All your points are >> valid. Thank you for sharing them. >> >> This was the first and, in all likelihood the last time such an >> unusual circumstance will arise. There is no right or wrong way of >> handling these things. >> >> Had we included x then y would have felt excluded, this is what we are >> seeing here. However, the line must be drawn somewhere. >> > > Surely at the ASF the line is at PMC membership. If only a subset of > the PPMC is trusted enough to be part of some inner circle then the > PPMC should be disbanded and reformed from just that inner circle. > Equally for the Incubator PMC, if Noel or who ever was chair should > have been told then the Incubator PMC should have been included. I'll refer to httpd, since it has the longest track record of security incident handling. There is about 1/4 of the httpd PMC who choose to be active as part of the security list. That group will go to the effort to respond to reports, test reported defects, write patches, test patches and help get the trunk or branch into some state that we can have a release. If the incident is (or becomes) publicly known, the security@ list wipes their hands of it, this mechanism is only used for embargoed issues. There is sometimes a parallel discussion on security@ when a publicly discussed flaw or patch has undisclosed security implications, but that's pretty rare. Well over half of the httpd PMC doesn't participate a whole lot in the first place, including voting on release candidates, so expanding the knowledge of undisclosed vulnerabilities to that group makes zero sense. As a PMC member, any of them would be welcome to join the security team, just as any can leave it if they don't have time or interest to follow the security space. I don't think we can compare the current AOOo situation; the "PMC" here is effectively the IPMC, the only group of people with binding votes. 95% of that PMC should not have had advance knowledge of the specifics of these defects, because 95% have little to do with AOOo on a daily basis. The people who would do the testing/verification/patch authoring and further testing and verification needed to be on that list, but of course are not binding PMC members [yet]. And of course there are even meta security lists of lists in this case, owing to multiple projects which are based on the common source code and subject to the same or very similar defect exposures. So the AOOo has assembled a hybrid model of some mentors and some of those committed developers. Certainly the project is going to refine policy going forwards. If I could do it over at httpd, I'd suggest anyone who has not participated in the resolution of the past 'X' defects would be booted from that security team. [Gently nudged off might be more diplomatic.] Perhaps some combination of incidents and period of time. security@ participation is not some privilege, it's added responsibility to the PMC and project by each of its subscribers. But the point is that simply for issues of email transport compromise, the people subscribed to that list need to pay extra attention to strictly using ssl transport rather than plain text over public and private networks, and that list needs to be broadcast to those people who will act on those security emails, and to absolutely nobody else. AOOo will continue to refine its practices in security@ handling, and I'd trust them to make balanced and measured compromises from what I've observed so far in my role on the ASF Security Team. Upon becoming a TLP it will be much easier to balance karma, authority and responsibility for security fixes, and these will come much more organically from a then-shipping ASF package which already had been released by the whole of the PMC. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
