On Wed, Apr 3, 2013 at 4:58 PM, janI <j...@apache.org> wrote: > On 3 April 2013 22:30, Rob Weir <robw...@apache.org> wrote: > > > 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) > > > Hmmm that I think ldap would be the normal way of handling it, but it is > pure technical and not something the user sees. > > > > > > > > 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. > > > > > > Yes, that is how I understand subprojects. PMC can grant write access. > > > > > > > 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 > > > > > 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. > > > +1, I would prefer 6 month. > > > > > 2) Everyone else has authorization for /site, /ooo-site and /devtools > > > Are you sure about devtools, they they are equal to source in my opinion. > > I do work in /devtools/aoo-stats to maintain the python scripts that are used for gathering downloads statistics. I didn't think that anything in /devtools became part of a release.
In any case, I don't touch the AOO source code, but I do touch /devtools, so that is why I was suggesting that division. But I may be the the only one in that particular category. -Rob > > > > 3) Any committer can be added to the active list on demand. > > > +1 with emphasis on demaend, default is read-only > > > > > 4) New committers are explained this when they are voted in and asked if > > they want to be on the active list for Subversion. > > > > +1 > > rgds > Jan I > > > > > 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 > > > > > > > > >
