On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti <pesce...@apache.org> wrote:
> 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. > > Good to think in layers of security. An account that is not authorized is an account we don't need to worry about at all. Note: we have people currently authorized for our source code, who have *never* checked in code and who have *never* posted on the mailing list. I have a heard time believing that they are following best practices to avoid losing control of their Apache login credentials. > > 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 > Yes, though the "right" is a de jure right, not exactly equivalent to the technical authorization. But one should lead to the other on demand. > - 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. > > I'd do it like this: 0) Call it "active" and "dormant" statuses. This doesn't change status as a committer, just status of SVN authorization. 1) By default the active list includes only those who have made commits to those trees in the last 12 months (or some other suitable time period). "Ever" would be a fine time period as well. 2) Everyone else has authorization for /site, /ooo-site and /devtools 3) Any committer can be added to the active list on demand. 4) New committers are explained this when they are voted in and asked if they want to be on the active list for Subversion. Regards, -Rob Regards, > Andrea. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
