openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Proposal: Improve security by limiting committer access in SVN
Date Wed, 03 Apr 2013 20:08:12 GMT
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 [] 
Sent: Wednesday, April 03, 2013 10:46
Subject: Re: Proposal: Improve security by limiting committer access in SVN

J├╝rgen Schmidt wrote: [...]
>>> On 3 April 2013 14:39, Rob Weir<>  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 
"" scripts currently used for the committers group.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message