This requires making sure that the files in the repo are all assigned to
a Subversion group and all users who are supposed to be able to access
the repo are members of that group as well, right?
Are there potential umask issues, or does Subversion take care of
ensuring that group permission bits on the files and directories in the
repository aren't messed up by user umasks?
I think from what you wrote below, you may actually be suggesting to put
all the users' public keys into one account and have all the users
access via that account, which would avoid both of the issues noted
above but isn't really what the FAQ answer to which you referred says to do.
In any case, there's still a performance issue, since SSH's encryption
and small TCP/IP windows (except in current development SSH sources and
custom SSH binaries patched with the hpn-ssh patches) make transfers
over LANs much, much slower than they should be.
We're only planning on allowing Subversion access to people who are
either on our LAN or VPN'd in, so I'm not sure we want to take on the
overhead of requiring SSH to access the repository.
Thanks for the info!
jik
On 02/14/2008 06:56 AM, John Peacock wrote:
> Jonathan Kamens wrote:
>
>> We’re in the process of setting up Subversion in-house, and we want to
>> use svnserve in stand-alone mode (don’t want to use WebDAV because it’s
>> slower than svnserve, and don’t want to use SSH because it’s slower, has
>> less access control and requires creating accounts for all the users on
>> the Subversion server).
>>
>
> Just FYI, there is absolutely no reason to eliminate svv+ssh from consideration
> because you don't want to give all users logins:
>
> http://subversion.tigris.org/faq.html#ssh-svnserve-location
>
> That is actually a much more secure methodology, since it doesn't require the
> user to remember any password - other than their private key's, if they set one
> - which is much more secure than any password.
>
> And doing it that way has no effect on whether you use the internal access
> control available to svnserve.
>
>
> John
>
Received on 2008-02-14 14:10:19 CET