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