Am 04/03/2013 10:58 PM, schrieb janI:
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
I'm one of them who would loose commit permission to the core code. But
for me it would be OK.
As my knowledge is not big enough to play with you in this "premier
league" of C++/C, Java, etc. it doesn't make any difference for me if I
could or could not commit. So, if it helps to increase the security a
bit, then I'm fine with it.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
