<rbb@rkbloom.net> writes:
> 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).
Pserver is one particular point in the security/convenience continuum.
Many sites use it (and no, not only public sites, by the way; I've
seen plenty that use it for private data). No, it's not the most
secure, but it's secure enough for a lot of uses, and SVN has to to
offer an equivalent.
> 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.
It would be useful to have a catalog of our auth methods and how we
store their data, at this point. We've got:
http basic auth -- Stored in cleartext, and goes over the wire in
cleartext too. Basically like CVS pserver.
At least, it *will* be, once we stop storing
the auth data in the working copy! :-)
ssl -- Stored in cleartext, but goes over the wire
encrypted. Like CVS pserver over an ssh
tunnel. Secure as far as the network goes,
not so secure from attacks based on the client
host.
ra_svn ssh tunnel -- No cleartext password stored on client side;
basically, this is like CVS's ":ext:" protocol
when run over ssh. It's only ra_svn, though,
right?
Anything else? (Not a rhetorical question; quite possible I've missed
stuff here, or misunderstood our existing options, in which case
please educate me.)
From the above, it looks like we have about the same range and kinds
of options as CVS, though unfortunately spread across two ra methods
at the moment. svn-agent will help fix that.
However, It's a fallacy to think that "Our basic storage method is
less secure than svn-agent; therefore svn-agent is objectively
better."
I *know* svn-agent, done right, is more secure. Just like CVS using
:ext:/ssh is more secure than CVS pserver. No one would deny this,
and it's not what I'm talking about. But:
"More Secure" != "Better"
The fact is, pserver is easier to use, and that's a tradeoff that many
people have decided to make. You may think they're crazy, but they're
doing it for a reason.
A passphrase-encrypted password on disk is extremely secure, but it's
also a bit harder to work with. Therefore, svn-agent is not a
replacement for what we have now. It is *another security option*, a
fine one, one we ought to have, +1 and all that. But it does not
replace other, less-secure-but-more-convenient methods; let's stop
pretending that it does.
It's great that you plan to implement svn-agent. Go for it, we need
it! However, Subversion still has to fix the auth storage problem in
the basic, unencrypted auth case. This is independent of svn-agent.
I feel like what I'm saying is not controversial; yet somehow people
keep coming back with slightly orthogonal responses. Is there
anything unreasonable in the statement
Subversion should offer at least the same range of
security/convenience tradeoffs as CVS does.
?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 16 17:39:17 2003