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

Re: [RFC] Integrating Cyrus SASL into Subversion

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-06-05 12:06:10 CEST

Vlad Georgescu wrote:
> Properly implementing SASL support in Subversion will require some
> refactoring:
>
> * On the client side:
> Authentication is performed by the following functions in
> subversion/libsvn_ra_svn/client.c : find_mech, auth_response,
> read_success, do_auth. (There's also handle_auth_request, but it only
> checks to see if the mechansm list is non-empty and then calls
> do_auth).
>
> Basically I want to extract these functions from client.c and put them
> in another file (say, "old_auth.c"). The entry point for
> authentication would be do_auth. I would then create a new file
> "sasl_auth.c" that also exports do_auth but does authentication
> through Cyrus SASL.
>
> The idea is to conditionally compile and link only one of those files
> depending on whether or not SASL is present on the system.

OK, sounds fairly reasonable.

A question (same one as Daniel and Branko): Is there really absolutely
no circumstance in which we would want the existing code, when compiled
to use SASL?

Please name the file something like 'trivial_auth.c' - *not* old,
because it is never going to go away, because we do not want to
institute a hard requirement on a SASL library.

Lastly, one piece of advice - altering the build system to support
conditional compilation and linking of files is likely to be more
trouble than it is worth. Just use #ifdefs - even if you end up
surrounding the entire content of a file in them.

> * On the server side:
> The relevant file here is subversion/svnserve/serve.c. We still want
> to put the old auth functions in another file, and create a new file
> for SASL. However, since we want to default to NOT using Cyrus SASL
> (because it's more difficult to configure) we will use both files. To
> enable SASL, we should use an option in svnserve.conf (something like
> "auth-type = sasl")
>
> There's also the question of what to do with libsvn_ra_svn/cram.c.
> This file contains the CRAM-MD5 authentication functions that should
> probably go in the "old_auth.c" files, but also some utility functions
> such as hex_decode and hex_encode that I still need to use in my
> implementation.

Leave the CRAM-MD5 stuff in cram.c, I think.

As a first step, make the functions in cram.c that you need in other
files visible throughout libsvn_ra_svn (non-static, appropriate name
prefix, declared in library-local header file).

Then, moving them to a more appropriately named file can be done as a
separate change.

Max.

Received on Mon Jun 5 12:06:53 2006

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.