On 16 Jan 2003, Karl Fogel wrote:
> Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de> writes:
> > No, I meant the way ssh-agent works: encrypted key on disk, plain text
> > key (or passphrase) in memory. Else, you would have to type your
> > passphrase each time it is accessed and nothing would be won (in terms
> > of usability).
>
> Sorry; of course you're right. But the point remains that now we've
> introduced another passphrase into the user experience.
>
> Hmmm. We're getting a bit off-track here, as far as immediate,
> pre-1.0 concerns for Subversion. All I'm trying to say is:
>
> 1. We currently store passwords in the working copy. Ryan has
> correctly pointed out that this is bad, because it makes sharing
> working copies a security compromise.
>
> 2. If we store the auth data into ~/.subversion/ (or equivalent)
> instead, we move up to the same security as CVS, which, after
> all, is the software we're trying to replace.
>
> 3. With svn-agent, we can get even more security, but at the cost
> of additional inconvenience for users and additional development
> and maintenance complexity for ourselves. Therefore, although
> svn-agent is certainly a good idea, it cannot be our only 1.0
> security option. We should first support option (2), because
> that's the security/convenience tradeoff people are accustomed
> to from CVS (and it's a sensible one, for this application).
>
> That's the big picture, IMHO.
I still disagree that implementing #2 brings us to the same point as CVS.
CVS only caches passwords to your disk if you are using :pserver:, which
most sites just don't do unless they are offering anonymous CVS. (Yes,
there are some that do, but it is rare).
What that means, is that by implementing #2, you have brought subversion
up to the very least that CVS does. This makes subversion useful for
public access, but leaves it unsuitable for use with private passwords.
Emulating a feature of CVS that most people consider to be a security
problem does not sound like the correct way to replace CVS.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 16 16:57:39 2003