openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Proposal: Improve security by limiting committer access in SVN
Date Wed, 03 Apr 2013 22:19:03 GMT
Am 04/03/2013 10:58 PM, schrieb janI:
> On 3 April 2013 22:30, Rob Weir<robweir@apache.org>  wrote:
>
>> On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti<pescetti@apache.org>
>> wrote:
>>
>>> J├╝rgen Schmidt wrote: [...]
>>>
>>>> On 3 April 2013 14:39, Rob Weir<robweir@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message