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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 14 23:34:02 2003