Sorry for talk posting. I get it now. If AOO is more secure than other Apache projects than this may give the impression that the other projects are less secure because they do not take these precautions. No project can be better than others since that implies some are worse. So any attempt to improve must be resisted since it reflects poorly on the projects that don't.
I apologize for not noticing this before. I understand completely. It is a very human reaction. I guess I'll just wait for the time to come for other projects to figure this out, through whatever painful lessons await them, so we can then move forward together, at the same pace. -Rob On Thu, Apr 4, 2013 at 2:33 PM, Rob Weir <robw...@apache.org> 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 >> >> >
