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 ?? 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 > > > > >