On Thu, Apr 4, 2013 at 3:17 PM, janI <j...@apache.org> wrote: > On 4 April 2013 21:03, Rob Weir <robw...@apache.org> wrote: > > > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein <gst...@gmail.com> wrote: > > > > > Your proposal to alter the community structure is premised upon a > > > strawman risk. First, that it would occur. Second, that it wouldn't be > > > noticed. Third, that it would find its way into users' hands. > > > > > > > > So you are asserting that someone who put their name down on the > Incubator > > wiki in July 2011 and was named a committer by that act, but never ever > > showed up after that, never joined the dev list, never posted to the dev > > list, never contributed code or anything else other than a name on a > wiki, > > is a member of our community and it would be altering the committee > > structure if we removed their authz to our source code, even with the > > proviso that we would immediately restore it on request? > > > > Really? > > > > Just a stupid question from someone who have not been here for ages...the > person just described should loose the committer role, or are we granted > commitership for lifetime ?? > > "Typical" and "Apache OpenOffice" should never be used in the same sentence unless mischief is intended ;-)
But other projects, being a committer is permanent, aside from resignation or extreme cases. But for most projects becoming a committer requires being involved with the project, demonstrating merit, being voted in by a PMC, etc., just like you did. But with OpenOffice, there was a two week period of time when we rapidly bootstrapped the community by making people committers automatically, on day 1. All they had to do is put their name on a wiki page and return an ICLA and they were committers. No vetting, no vote. Quite a few of them never got involved in the project in even the least degree. So we have these phantom community members, with authorization to change the source code. Regards, -Rob > jan I. > > > > > -Rob > > > > > > > > > In the past, the Foundation has *explicitly* said that we would accept > > > a certain level of risk to maintain our communities. > > > > > > I find your strawman at a level even *lower* than the scenario that > > > I'm thinking about(*). > > > > > > If you're worried about stale committers suddenly inserting trojans, > > > then just use 'svn log' to find those outliers. No need to create > > > division within the community. Run a simple histogram. There are many > > > solutions to your purported attack vector, than to divide into groups. > > > > > > Cheers, > > > -g > > > > > > (*) a certain large company's lawyer (ahem) was trying to scare the > > > ASF ("the risk!!") into adopting certain procedures; we shut her down > > > > > > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote: > > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein <gst...@gmail.com> wrote: > > > > > > > > > Also, let me say one more thing: > > > > > > > > > > This notion of creating divisions among committers ... it is > > "solving" > > > > > a problem that has never occurred here. > > > > > > > > > > NEVER. OCCURRED. > > > > > > > > > > > > > > So frickin' what? That is entirely irrelevant. My house has never > > > burnt > > > > down either, but I still don't leave open flames around unattended. > In > > > > fact you might think this is naive view, but avoidance of such risks > > > might > > > > even be correlated with lack of house fires. Hmmm.... > > > > > > > > > > > > > > > > > In the Foundations's 14+ year history, we have never seen a trojan > > > > > commit. Our servers have been compromised a handful of times. When > we > > > > > were back on CVS, we even had to audit source control to verify no > > > > > trojan injection. But we have NEVER had a case of a malware commit. > > > > > > > > > > > > > > Again, that proves nothing. I'm sure the first time apache.org was > > > rooted > > > > that it had never happened before either, right? > > > > > > > > > > > > > > > > > > > > > So back to IMO: dividing and partitioning and separate privilege > > > > > levels... there is no reason. It creates a social problem to > "solve" > > a > > > > > non-existent issue. Net result: more problems. > > > > > > > > > > > > > > > > > > Greg, we already do this. Does every ASF Member have credential for > > > Infra > > > > root? Does ever ASF Member have access to legal-private mailing > list. > > > No. > > > > No. We even do this in the AOO project, with separate authz for > > > > openoffice-security, which by the way also includes an SVN tree. > > > > > > > > Anyone who thinks this is a question of dividing and privilege is > > > > expressing a knee-jerk reaction, without thinking of the risks. We > > > should > > > > avoid regurgitating platitudes. Remember, we're talking about people > > who > > > > have never committed code, who don't even know C, who are not even > > > > subscribed to the dev mailing list, and in some cases have never ever > > > > posted to our mailing lists. They signed up in with the podling in > > July > > > > 2011 and then were never heard of again. You make an extremely weak > > > > argument to pontificate about "privilege" here. > > > > > > > > The risks are real. High profile open source projects attract these > > > kinds > > > > of attacks. There are those who know it, and those who don't know it > > > yet. > > > > > > > > A good read: > > > > > > > > > > http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked > > > > > > > > As for those who think that casual review of commit messages will > > review > > > > any attack, that is a dangerously naive few. We should not expect an > > > > attack to be in a filed called trojan.c with comments and clear logic > > > > explaining what the code does. Any hacker with a clue would send a > > patch > > > > backed by a reasonable defect report in Bugzilla that would be > > innocuous > > > to > > > > casual inspection. All you need is a buffer or stack overwrite in a > > > > well-placed area to cause the problem. This might even be done in > two > > > > stages, spread out over time, so the impact is not detectable without > > > > looking at the pieces together. > > > > > > > > Now if someone did that in the name of an active committer it would > be > > > > *immediately* detected. "WTF!? I didn't check that in!" But when > > done > > > in > > > > the name of an unactive committer it would be less likely to be > noticed > > > for > > > > what it is. We might check twice, but that doesn't mean we'd catch > all > > > or > > > > even most deliberate attacks. But whatever detection rate we would > > have > > > > there it would be far less than the presentation rate for not having > > > > authorization enabled at all. The prevention rate there is 100% > > > > > > > > Regards, > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > On Thu, Apr 04, 2013 at 05:59:31PM +0000, Greg Stein wrote: > > > > > > Speaking as one of those "old-hands", Dennis is absolutely > spot-on. > > > > > > > > > > > > Partitions, barriers, sub-groups... I call those "divisive" > > > mechanisms > > > > > > which serve to divide the community. Such divisions are rarely > > > needed. > > > > > > > > > > > > As Andrea points out, in Subversion's 13 year history, we have > only > > > > > > *requested* people observe certain fences. We have never had a > > > > > > problem. We have never had to take sanctions. A stray commit here > > and > > > > > > there? Sure, it has happened, with the best intent, so we just > > point > > > > > > out that they need a bit more caution. No harm done. > > > > > > > > > > > > Back to Dennis' point: the solution here is proper review of the > > > > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* > the > > > > > > potential contributions of others. > > > > > > > > > > > > Cheers, > > > > > > -g > > > > > > > > > > > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton > wrote: > > > > > > > In previous generations of this kind of discussion, the ASF > > > old-hands > > > > > will point out that the social process works quite well, folks > don't > > do > > > > > commits unless they feel qualified to do so, and it is often the > case > > > that > > > > > committers will request RTC (i.e., submit patches rather than > update > > > the > > > > > SVN) in contributing where they are not experienced or don't > consider > > > > > themselves expert. > > > > > > > > > > > > > > At the ASF this appears to be one of those, "if it is not > broken, > > > > > don't fix it." > > > > > > > > > > > > > > There is still the concern about stolen credentials used to > > perform > > > > > undetected malicious acts. If the oversight that the project > > naturally > > > > > brings to bear on visible changes to the code base is > insufficient, I > > > think > > > > > the problem is greater than there being a possible exploit of that > > > > > inattention. Mechanical solutions may be part of the disease, not > > the > > > cure > > > > > [;<). > > > > > > > > > > > > > > - Dennis > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > > > > > > Sent: Thursday, April 04, 2013 08:57 > > > > > > > To: dev@openoffice.apache.org > > > > > > > Subject: Re: Proposal: Improve security by limiting committer > > > access > > > > > in SVN > > > > > > > > > > > > > > Dave Fisher wrote: > > > > > > > > Let's focus only on adding one new authz list for the code > > tree. > > > > > > > > Call it openoffice-coders and populate it with those who HAVE > > any > > > > > > > > commit activity in the current code tree. > > > > > > > > > > > > > > I checked feasibility with Infra. Summary: > > > > > > > > > > > > > > 1) LDAP is not the solution. Rule it out. > > > > > > > > > > > > > > 2) The only possible solution would be an authz rule like > > > suggested by > > > > > > > Dave here; however, Infra quite discourages it, mainly for > > > maintenance > > > > > > > reasons. This leads me to think we would need some good > > > justifications > > > > > > > for implementing this. > > > > > > > > > > > > > > 3) If the justification is security, then there are other > > > privileges to > > > > > > > monitor. Namely, every committer has shell access to > > > people.apache.org > > > > > , > > > > > > > authenticated access to the Apache SMTP server and CMS > privileges > > > for > > > > > > > the openoffice.org website, including publish operations. > > > > > > > > > > > > > > For the record, the Subversion project has complex rules like > Rob > > > > > > > pointed out; but it's only a "social enforcement", i.e., all > > > committers > > > > > > > respect those limitations by their own choice; if you look at > the > > > > > > > technical level, every committer (all Apache committers) can > > commit > > > > > code > > > > > > > to the Subversion subtree. > > > > > > > > > > > > > > Regards, > > > > > > > Andrea. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > > > > For additional commands, e-mail: > dev-h...@openoffice.apache.org > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > > > > For additional commands, e-mail: > dev-h...@openoffice.apache.org > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > >