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