You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/12/03 17:23:21 UTC
Re: connection establishment todo, secure transport, sasl temporary
alternative
As Garrett pointed out, ra_svn doesn't use Apache. And one of my goals
in writing ra_svn was to eventually support the full range of SASL
mechanisms, not the limited range of authentication options available
through HTTP. SSL and ssh may be good enough for 90% of the user
population, but there are krb5 sites (like my workplace), and SRP sites,
and OTP sites, and smartcard sites, and it would be nice if Subversion
could fit into those infrastructures.
Anyway, a goal of what's listed in todo is to make it impossible to use
plain-text passwords with ra_svn. If the client and server send a
secret, there is no good reason to compromise that secret by blatting it
over the network in the clear. Plain-text passwords over SSL is secure,
but openssl is not a mandatory dependency of Subversion.
I'm still a bit nervous about implementing a native username/password
mechanism at all (whether PLAIN or CRAM-MD5 or SRP), because it wouldn't
be possible for us to be file-format compatible with Cyrus-libsasl on
the server. So maybe the native code will only implement ANONYMOUS and
EXTERNAL (for EXTERNAL read "tunneled over ssh"), and you'll have to
link in libsasl for anything else.
(Once libsasl is integrated, SSL will be possible via the STARTTLS
mechanism.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: connection establishment todo, secure transport, sasl temporary alternative
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Tue, Dec 03, 2002 at 12:23:21PM -0500, Greg Hudson wrote:
> As Garrett pointed out, ra_svn doesn't use Apache. And one of my goals
> in writing ra_svn was to eventually support the full range of SASL
> mechanisms, not the limited range of authentication options available
> through HTTP.
Not to say that you couldn't use SASL as an HTTP auth protocol, of
course (I'm working on this for neon at the moment, as it happens).
http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org