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/4530This 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@... (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.
_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel
