[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue 1144 - sasl support in svnserve

From: David Anderson <david.anderson_at_calixo.net>
Date: 2005-11-10 13:37:48 CET

Lars Gullik Bjønnes wrote:
> I take it that only server-side certificates will be required, and
> client side optional?

That still has to be discussed, but that would be my thoughts.

> Ok, so the task is not as "simple" as issue 1144 might convey?
>
> Wrt SASL, what specific design issues need to be tackled?
> (I might have some resources to contribute.)

The infrastructure for integrating SASL is in place (it was thought into
the svn wire protocol from the start). However, there are design issues
that need to be thought about before integration.

Actually, a lot of them have to do with SSL integration, which is a
dependancy for SASL (without a secure transport layer, a lot of SASL
mechanisms are insecure). Things like when should the option to
escalate to a secure transport be offered during a protocol exchange,
how to preserve URI anonymity without compromising backward
compatibility... Max Bowsher was planning on writing a small piece to
the list about this, but I think he had computer problems and it got
delayed.

Concerning SASL alone, I believe the biggest question we have is what
SASL library (if any) to use. The contenders are Cyrus SASL, GNU SASL,
and the SASL mechanism library integrated in the Dovecot mail daemons.

 From the echoes I've had, Cyrus SASL has problems relating to APR and
multithreading properly; GNU SASL is largely incomplete; Dovecot SASL is
an interesting alternative, but it is currently integrated in Dovecot,
and only implements the server side of things, so it would require
factoring the SASL code into a separate project, and writing the client
SASL code into it.

Then of course, there is the option of writing our own. But I reckon
that if Cyrus and GNU SASL fail us, we'd be better off completing the
(already good) SASL code of Dovecot, rather than reinventing everything
again.

Once the choice of the library is made, I think there will have to be
some API discussion, as for complete SASL support the current
authentication callbacks in the client seem to me to be insufficient.
But that is all fairly small discussion, as the basics of auth
mechanisms and mech negociation is already in the actual wire protocol.
  The big questions come with SSL and which SASL library to use.

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 10 13:41:26 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.