Sarcasm accepted. Thank you. On Thu, Apr 04, 2013 at 02:54:41PM -0400, Rob Weir wrote: > 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 > >> > >> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
