[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Passswords not encrypted

From: Joseph Mocker <mock+svn_at_fakebelieve.org>
Date: 2007-06-13 19:37:19 CEST

Benjamin Podszun wrote:
> Joseph Mocker wrote:
>> What would be nice is an "ssh-agent" type of capability for
>> subversion. Where one could authenticate once for a session, and the
>> agent would keep track of the authentication/password. When
>> authentication is needed, subversion would query the agent first.
>
> Why don't you use svn+ssh then?

Main reasons, per the "red-bean" subversion book:

    * Requires users to be in same system group, or use a shared ssh key.

    * Can lead to file permissions problems.

Coming from similar headaches with CVS, I didn't want to deal with that
again, svnserve seemed a good choice to not have to deal with that.

Also, unless there is a trick I don't know about (which there probably
is), the svn+ssh URLs to the repository include full pathnames to the
location of the repository on the server. So if I decide to move that
location, I have to tell all my developers to update their URLs. OTOH,
svnserve abstracts that for you.

I do use svn+ssh for one (private) repository for myself, but currently
for the group repository we're only using svnserve.

Hmm, thinking about shared ssh keys, actually I could probably create a
single server account with the users keys added to .ssh/authroized_keys
file, and people would access svn via that account. That would mitigate
permissions issues, but then do changes get logged as the original
user, or the server account?

  --joe

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 13 19:39:48 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.