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