On Thu, Apr 4, 2013 at 3:59 PM, Joe Schaefer <joe_schae...@yahoo.com> wrote:
> Ah NO. Those so-called "phantom" committers > had their commit to this projext revoked when you graduated > Hi Joe, See the list here: http://people.apache.org/committers-by-project.html#openoffice I've been tracking the length of that list since July 2011. It has not decreased. You can see that here: http://www.openoffice.org/stats/committers.html Maybe you are thinking of openoffice-pmc? I know the PPMC list was reduced when making the TLP's PMC, but did anything happen to the committers list? > to a TLP, but the larger point that Greg's making > remains true- it is a false sense of security to > rely on ACL's to pretend you don't need to vet your > commit list. See http://www.apache.org/dev/open-access-svn > for more details of an ongoing debate to simplify > our svn rules accordingly. > One of our issues is that being a committer enables access to multiple systems. some controlled by LDAP, some by authz and some manually, e.g., access to editor rights in the blog. I think there is room for having someone be a committer and having access to all the systems that they want access to for the work they want to do, without assuming that they need access to everything just because they are committers. This might be different in projects where 99% of the commiters are coders. But in our case, our demographics is far different. I hope we all appreciate that this difference exists. Regards, -Rob > > > > > > >________________________________ > > From: Rob Weir <robw...@apache.org> > >To: "dev@openoffice.apache.org" <dev@openoffice.apache.org> > >Sent: Thursday, April 4, 2013 3:53 PM > >Subject: Re: Proposal: Improve security by limiting committer access in > SVN > > > >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.orgwas > >> > > 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 > >> > > > >> > > > >> > > >> > > > > > > >
