I know a number of sites, including Collabnet, would find ra_svn more
acceptable if it sported authentication options other than "give
developers accounts and tunnel over ssh." I'm not sure how much of a
1.0 priority this should be (we have ra_dav, after all), but I know
some people would appreciate it.
Unfortunately, there's a bit of a stumbling block. I was planning to
integrate Cyrus SASL as an optional dependency, which would get us a
whole pile of authentication types (CRAM-MD5 and GSSAPI/KRB5 and maybe
SRP are probably the most notable; I expect that STARTTLS would become
an option in the future), but it uses a dynamically loaded plugin
architecture. This means it needs to run an initialization step once,
since you can't dlopen() libraries multiple times. (Perhaps I'm wrong
about that, but regardless, Cyrus SASL documents that it wants to run
an initial step once before any other calls are made, or it won't be
thread-safe. I'm also supposed to hand it mutex-locking callbacks for
it to be thread-safe.)
My problem is that APR doesn't provide any kind of locking to ensure
that an initialization step is performed once. It has mutexes, but no
static mutex initializers. It has the concept of a "once", but again,
there's no static initializer for a once.
The options I see are:
* Introduce an svn_initialize() which applications have to call
instead of (or in addition to) apr_initialize(), before forking
any threads. Have it invoke initializers for each ra layer, and
make ra_svn provide one which intializes the SASL library.
* Implement our own SASL mechanisms and just accept the bulk. (We
wouldn't be the first; Evolution does this, for instance.)
Without writing too much code, I could probably implement CRAM-MD5
and maybe STARTTLS (using OpenSSL, of course).
* Rip out the SASL stuff in the ra_svn protocol (or leave in the
stubs we have, although that might be confusing in the long run)
and provide a tunnel agent which uses SASL for authentication.
* Keep the current protocol, but do the SASL stuff in a subprocess
(without using the tunnel-agent mechanism). If you don't have
thread-safety, there's always processes.
* Do nothing.
Opinions? I'm not sure how to best balance architectural cleanliness
with administrative convenience. Library integration seems the most
transparent to the adimnistrator, but provides the most architectural
headaches.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 31 08:38:46 2003