Integrating Cyrus SASL

[Havoc Pennington]

Hi,

On Wed, Dec 31, 2008 at 1:39 AM, Ryan Saunders <jediry01 at yahoo.com> wrote:
>
> After slogging through dbus-auth.c, as well as the Cyrus SASL documentation (and occasionally, the source code), I have succeeded in hacking together a rough integration of Cyrus SASL 2.1.22 into DBus 1.2.3. The implementation is quite hacky in places, but I am now able to make a few DBus calls across a TCP link using PLAIN authentication. Now that it works, my next step is to polish it up, so that it's worthy of being submitted as a patch to DBus.

Awesome! (Once you have this ready for review, be sure to add it to
bugzilla as well as the mailing list.)

> Issue #1: How should libsasl2 fit into the auth mechanism handlers?
> ---------------------------------------------------------------------------------------
>  1. Integrate libsasl2 using the current set of auth mech handler callbacks, in a similar fashion to how the existing mechanisms are coded.
>  2. Put libsasl2 in charge of *all* authentication mechanisms,

The main difference here is in whether there's a hard libsasl2
dependency. Any opinions on that from GNOME upstream, Ubuntu, Fedora?
maybe someone will chime in.

Also, what is the libsasl2 license?

I think option 1 is pretty easy really; I'd change the runtime
representation to a DBusList instead of an array, and just use the
static array to populate the list, and then also use libsasl2 to add
more stuff to the list.

> Issue #2: How to expose the auth conversation on the client slide?
> ---------------------------------------------------------------------------------------
>  1. Allow client to specify libsasl2 callbacks and interaction structures directly.
>  2. Wrap the libsasl2 interactivity stuff with a (probably very similar) DBus interface, and require DBus clients to implement that instead.

I think the best-working solution would be to make the interactivity
UI a separate process that is per-user-session. It would be a
singleton dbus service on the session bus.

If you try to do it in each app, in practice it just won't end up
working; there will be problematic interactions with other code in the
app, and bunches of apps won't implement it at all.

It could be OK to allow apps to set the callbacks (probably we'd wrap
libsasl2 callbacks API with a "dbus native" C API in dbus.h) but I
think that would only be for special apps, and there would be some
default implementation that used a singleton dbus service on the
session bus.

As you code all this, remember to run (and hopefully add to) the unit tests.

Havoc