I've just added a couple of fixes for the Cyrus SASL support code in
the gaim Jabber module to the Sourceforge patch tracker.
The first of these fixes gaim to correctly pass in the FQDN of the
server we're talking to, rather than using the user's realm (which
doesn't always match). The second fixes a hang when using SASL
security layers (which only really occurs with the GSSAPI or DIGEST-
MD5 mechanisms).
Judging from the comments in the code, there's some confusion about
the way in which the control flow in the SASL connection routine
works - as I originally wrote it, perhaps I can shed some light on it.
The problem with Cyrus SASL is that the client and the server both
provide it with a list of mechanisms, it tries the best mechanism,
and expects that to succeed. Unfortunately, when you're dealing with
X509 or Kerberos based mechanisms that rely on local credentials,
there's no guarantee that mechanism failure is due to the user's
password being correct, or that mechanism failure is a reason to
retry, rather than trying the next available mechanism. So, what the
code does is take the list of mechanisms provided by the server, and
then lets Cyrus pick the best one and try it. If that mechanism
fails, then it is removed from the list of available mechanisms, and
Cyrus is allowed to try another.
In this way, we can try SASL mechanisms such as GSSAPI against a
server that claims to support them, but fall back to using password
based authentication should GSSAPI fail, without having to prompt the
user.
Hope that helps,
Simon.
|
