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

Re: Writing svn-agent (Was Re: [PATCH] default to --no-auth-cache)

From: <rbb_at_rkbloom.net>
Date: 2003-01-14 23:47:04 CET

Well, how are your friends who can't get ssh-agent working using ssh? Do
they have passphrases in their keys? If so, then they are typing their
passwords all the time. If not, then svn-agent will work the same way as

The only place that svn-agent doesn't replace auth caching, is if you
aren't using client-side certs, and you don't have svn-agent running.
If we can make svn-agent easy to use though, this case will go away.


On 14 Jan 2003, Karl Fogel wrote:

> svn-agent is not an equivalent substitute for on-disk caching. Y'all
> hang out with too technical a crowd or something, I think :-). Many
> people will not remember to start up their agents. People will not
> understand how it works. They will be confused, then they will read
> the docs and be more confused. (I know plenty of people who can't get
> ssh-agent working right. They're not stupid, they just have other
> things to pay attention to.)
> "Oh, Subversion itself will start the agent!" But what if one's
> already running? "It'll cache a PID file in ~/.subversion/, and
> Subversion will check there first!" And what if the machine crashes
> before that PID file has a chance to be removed? "Well, if Subversion
> tries to contact the process and can't, it'll erase the PID file and
> start a new one." So superuser could crash the machine and restart
> with a trojan horse at the old agent PID, and harvest passwords? Or
> heck, why not just replace the binary with a trojan horse in the first
> place, if you're root?
> In other words, this is not really any more secure than just storing
> the auth data in a ~/.subversion/ area readable only by the user (I
> hope & assume Windows per-user registries are equally secure.)
> But it *is* a lot more complex, in terms of portability, code
> complexity, and number of things that can go wrong at run time.
> What's our win here? I'm not seeing it.
> -Karl

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 23:34:02 2003

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

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