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

[Simon Wilkinson]

On 20 Mar 2008, at 17:33, Greg Hudson wrote:

> 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

This is a bug. I took a look at Greg's patch in January, decided I  
needed more context to review it fully, and it promptly got buried by  
a load of other work. The general aim of the patch is correct, but I  
would like to see what the other implications of combining host and  
fqdn are in that function.

>   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.

Yes. This is Openfire's bug. Its _really_ unclear what the correct  
thing to send as an authorization name is when you're using GSSAPI  
with XMPP - is it a Kerberos identity, or a JID? The problem is most  
servers object if you send a JID here (quite a lot just check that  
authn == authz, which of course fails where authn = sxw, but  
authz=sxw at inf.ed.ac.uk (my JID)). The whole thing needs to be better  
specified. Against this, just sending no authz name (which means that  
the server should use whatever it can derive from your authn) is the  
safest path.

As a data point, I'm using Adium against a GSSAPI enabled server on a  
daily basis, without any issues. Having Adium built against Cyrus  
SASL has been a huge win for us!

Cheers,

Simon.