Integrating Cyrus SASL
Havoc Pennington
hp at pobox.com
Thu Jan 1 06:46:57 PST 2009
Hi,
On Thu, Jan 1, 2009 at 6:20 AM, Ryan Saunders <saunders at aggienetwork.com> wrote:
>> Also, what is the libsasl2 license?
>
> It looks pretty liberal. Googling for it, I found this: http://www.zimbra.com/license/cyrus-sasl.txt
> IANAL, but it seems to say "do whatever you want, just don't say you wrote it, or that we endorse your product".
Great, looks fine.
> I'm not sure I understand what you mean...the libsasl2 "interactivity" stuff is on the _client_ side of the connection, and the whole point of this is to authenticate the app to the session bus...I'm not understanding how the client app could gain access to a session bus service before authenticating itself. Can you clarify?
I can clarify that I wasn't thinking clearly ;-) Right, hmm. So the
dbus session bus interactivity approach would be appropriate for
anything *except* dbus.
The problem remains that apps won't implement those interactivity
hooks reliably. I don't have an objection to adding them; I would wrap
them in a nice libdbus-looking API though. But it will be years (at
best) before you could really use an interactive auth mechanism with a
generic desktop app and expect it to work.
In the context of a desktop session, nothing that has to interact
per-app is at all sane for the session bus, would drive users nuts.
The only thing that would be usable for the session is something like
Kerberos where your auth is remembered. So maybe desktop environments
could cook up something where some special app authenticates first in
the session, before other apps then start up and try to auth, so only
the first special app would have to implement interactive auth.
If that sounds plausible then you could add the interactivity hooks
and leave this for gnome, kde, etc. to solve.
Havoc
More information about the dbus
mailing list