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:13:02 2003