On Wed, Apr 3, 2013 at 4:08 PM, Dennis E. Hamilton <orc...@apache.org>wrote:
> I'm not clear why a non-LDAP solution is required: > > 1. Being a committer is specific to a project. What it means to be a > committer on a project is very well-defined. > > And in some Apache projects they do exactly what I am proposing. For example, Subversion has full committers, partial committers and dormant committers: https://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS > 2. The SVN repositories of the public ASF projects are publicly > read-only. That's a no-brainer. They are only writable to those who have > SVN permission by virtue of being committers on this project. That's > project specific. There's an authz file that does it. > > Some other SVN repositories are also writeable by virtue of being > committers at the ASF. That seems to be ASF-specific. > > Sort of. They are writable because of the authz. How exactly that is connected to committership is up to the project and is what is under discussion here. > It makes no sense for a committer who is established as a committer of > this project to *not* have committer privileges on the SVN. It's what > committer *means.* > > Actually, it makes no sense to be in the authz file unless you intent to change files in Subversion. If you have the permission but never intent to use it, then you are merely raising the security risk for the project. > The necessary ceremony was the acceptance of a committer invitation (or > being grandfathered as an initial committer who completed the necessary > steps). > > If there are now trust issues, I think the proposed solution is > ineffective. If there is a concern about inactive committers, address that. > > It is not about trusting the committers. It is about reducing the exposures to hackers. Trust of the committer has nothing to do with it. Every active authorization in SVN is a vulnerable opening for a hacker, who can gain access, via any number of phishing methods in common use today. It us only prudent that a committer not have that authorization unless they are using it. -Rob > - Dennis > > -----Original Message----- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Wednesday, April 03, 2013 10:46 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > Jürgen Schmidt wrote: [...] > >>> On 3 April 2013 14:39, Rob Weir<robw...@apache.org> wrote: > >>>> one change to our current process that will, I think, greatly increase > >>>> security. This would be to restrict SVN authorization for the code > > I don't think this would greatly increase security, since the current > review model would still be the better defense. But surely this doesn't > decrease security and doesn't impact on people who are not using it. > > > I see also no problem if we handle it more careful and give svn access > > to the code on demand only. Nobody should take it personal > > Before we manage again to make simple discussions complex, let's see: > - All committers have the right to have write access to the source code > - By default 3 subtrees (trunk, tags, branches) are read-only > - Any committer can receive write access to the 3 subtrees immediately, > by sending an e-mail here > > This could be fine for me, provided that: > > 1) We have the right way to manage this (another LDAP group does not > look like the right solution: people who don't want to understand > correctly will invent that this is a multi-level hierarchy while it > would simply be a permission that we enable on demand) > > 2) Enabling write access is extremely simple, especially if this is > something that I must take care of! Something like the current > "modify_unix_group.pl" scripts currently used for the committers group. > > 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 > >
