pidgin: 3161d3b0: Now that Adium has cyrus-sasl enabled, I...

[Greg Hudson]

On Wed, 2008-03-19 at 20:59 -0400, Evan Schoenberg wrote:
> Take a look, for example, at the logs in http://trac.adiumx.com/ticket/9492 
> .  Upon updating from Adium 1.2.3 (libpurple 2.3.1) to Adium 1.2.4  
> beta (libpurple 2.4.0), GSSAPI began actually working for this user  
> and his friend; I'm not sure why it was broken previously.

When I investigated this for Ken, I uncovered three bugs:

  1. libpurple selects the wrong server FQDN for SASL authentication if
a connect server is specified.  The workaround is to use a SRV lookup
instead of a connect server.  http://developer.pidgin.im/ticket/4530

  2. Openfire 3.3.x gives a spurious authorization error for GSSAPI
authentication against libpurple, because libpurple does not specify an
authz name (which should be perfectly acceptable but it triggers a bug).
Fixed in Openfire 3.4.x, but MIT is not running this yet.

  3. Adium successfully falls back from GSSAPI to password auth if
GSSAPI auth fails early enough (e.g. due to bug #1), but not it if fails
late enough (e.g. due to bug #2).  In the latter case, it repeatedly
asks you for your password but never manages to use it.  I did not
discover the code reason for this fallback issue.

I do not know if bug #1 or #3 were addressed in later Adium releases.

A GSSAPI checkbox isn't the end of the world from my point of view, but
it's definitely an "I know how to change the UI and I don't know how to
fix the actual bugs" type of workaround.