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

[Evan Schoenberg]

On Mar 19, 2008, at 8:35 PM, Stu Tomlinson wrote:

>> Now that Adium has cyrus-sasl enabled, I'm having a lot of users
>> report problems connecting to servers which ultimately turn out to be
>> that the server supports GSSAPI in addition to other mechanisms and
>> the user isn't configured serverside or clientside to authenticate
>> properly.  Generally speaking, a user/password combination is the
>> expectation for most people for connecting.
>
> Except where GSSAPI is configured for a reason, and I don't see why it
> would be available otherwise.

The biggest category of problems I've seen is that iChat Server  
enables GSSAPI by default.  Other situations seem to involved in  
people moving between work and home environments.  I honestly don't  
follow it all; I just know that GSSAPI support has been both a  
longtime request (which led to us enabled cyrus-sasl with GSSAPI in  
our binary) and the source of a huge percentage of support headaches  
once enabled.

Part of this, obviously, is Users Being Dumb.  Part of it is Apple's  
love for GSSAPI; the iChat client actually has a preference like the  
one I added in this commit which is also off by default, for I presume  
the same reasons.

>>> This adds an account preference, off by default, which enables
>> GSSAPI authentication.  If there's a huge outcry against displaying
>> this preference in Pidgin and Finch, I'd appreciate leaving it in  
>> as a
>> 'hidden' preference (changed to TRUE by default) which UIs can use; I
>> plan to expose it within Adium.
>
> Please consider this my huge outcry!
>
> I spent quite some time getting Pidgin/libpurple with GSSAPI
> authentication and SSO working "plug and play" in an Active Directory
> environment. I don't want this preference hidden or otherwise.
>
> If the clientside is not configured at all for GSSAPI auth, it  
> should be
> falling back to other alternative authentication methods - if this is
> not happening, that is what needs fixing. If a client is incorrectly
> configured for GSSAPI authentication, adding a preference in all  
> apps is
> not the right solution.

Inclined to agree, though I'm frankly just frustrated by situations  
wherein being Right means that folks can't use our program at all  
despite wanting to.  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.

Previously, we had:
22:14:15: (Libpurple: sasl) Mechs found: GSSAPI PLAIN
22:14:15: (Libpurple: sasl) GSSAPI Error: Miscellaneous failure  
(Server not found in Kerberos database)
22:14:15: (Libpurple: sasl) sasl_state is -1, failing the mech and  
trying again
22:14:15: (Libpurple: sasl) Mechs found:  PLAIN

And now that GSSAPI is working, it finds a server, connects to it,  
fails to authenticate, and bails out.

Another solution to have people connecting successfully despite  
configuration problems out of their control might be that if a  
password is given and GSSAPI fails authentication to try the next auth  
method with the password.  I suspect that goes against some standard  
of how SASL is supposed to work, though.

> I hate workarounds for misconfigured clients or servers. If Cyrus SASL
> is causing so many problems for your Adium users, maybe you should  
> just
> turn it off and let things be?


There's a population of servers which require GSSAPI for  
connectivity.  I'd definitely prefer to find a good solution overall.   
What are your thoughts?

-Evan