Subject: [Wocky] How much does AdiumX 1.2.1 fix?

From: William Cattey <[email-masked]>
Date: Tue, 22 Jan 2008 20:57:38 -0500

Ken,

In your note of 6 January you provided results of your testing AdiumX  
1.2, and concluded that it was not ready.

What improvements, if any, are present in the newly-released 1.2.1?

I saw that they worked with some stuff relating to OpenFire, and to  
connect server setups.

-Bill

----

William Cattey
Linux Platform Coordinator
MIT Information Services & Technology

N42-040M, 617-253-0140, [email-masked]
http://web.mit.edu/wdc/www/

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 25 Jan 2008 00:58:04 -0500

On Jan 22, 2008, at 20:57, William Cattey wrote:
> Ken,
>
> In your note of 6 January you provided results of your testing  
> AdiumX 1.2, and concluded that it was not ready.
>

Yes, they've made some improvements, but there are still problems.

(First, if anyone besides me cares, Zephyr support is still broken.   
It *looks* like a trivial fix -- they use the wrong option to the  
configure script for libpurple -- but I haven't had time to actually  
test that.)

It appears that I need to specify the "connect host" of  
jabber.mit.edu, *and* use my password, to sign on to our main jabber  
server.  Once I do that, I get in okay.  If I don't have a connect  
host specified, I'm repeatedly prompted for my password as if I'd  
given an incorrect one.  So, GSSAPI authentication still seems to be  
a no-go, but I can sign on with the latest version much like with  
1.1.4.  I'm not sure why omitting the connect host causes even  
password authentication to break...

Ken

---

From: Greg Hudson <[email-masked]>
Date: Fri, 25 Jan 2008 11:46:54 -0500

> password authentication to break...

If you specify a connect host, GSSAPI authentication fails earlier,
because of the bug where libpurple selects the XMPP domain as the server
FQDN if a connect host is specified.  Presumably in this case the
fallback logic to using a password works.

If you do not specify a connect host, GSSAPI authentication fails later,
because of the server bug where authorization fails if the client
doesn't choose an authz name.  (The server upgrade is blocking on
scheduling issues with NIST, and is still scheduled for "soon".)  In
this case the fallback logic to using a password does not appear to
work; I guess the client asks for a password, retries the connect,
re-attempts GSSAPI auth, and repeats.