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

[nosnilmot]

On Wed, 2008-03-19 at 20:25 -0400, evands@... wrote:

> -----------------------------------------------------------------
> Revision: 3161d3b09a1cb0dfe2a905306fbe19a6e76f5531
> Ancestor: c8a7475750a83a32c26d2f40066500a948844beb
> Author: evands@...
> Date: 2008-03-20T00:20:27
> Branch: im.pidgin.pidgin
> URL: http://d.pidgin.im/viewmtn/revision/info/3161d3b09a1cb0dfe2a905306fbe19a6e76f5531
>
> Modified files:
>         libpurple/protocols/jabber/auth.c
>         libpurple/protocols/jabber/libxmpp.c
>
> ChangeLog:
>
> 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.

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

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?

Regards,


Stu.

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[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

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Evan Schoenberg]

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

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

Alternately, how would you feel about leaving the preference and  
defaulting it to TRUE?  This would allow users to work around  
configuration issues without disrupting the works-out-of-the-box  
nature of the current setup for most well-configured environments?

-Evan

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

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


_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[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@... (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

[nosnilmot]

On Thu, 2008-03-20 at 13:33 -0400, Greg Hudson wrote:

> 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

This issue was fixed in libpurple 2.4.0, as I explained in that ticket
now.

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

I brought this up on devel@... in October 2007 with a potential
workaround, but Openfire 3.4.x came out so I dropped the issue, hoping
everyone would upgrade to 3.4.x :)

--- libpurple/protocols/jabber/auth.c   be6b7606ec2984e0c958da8b43b3d1f55cb52938
+++ libpurple/protocols/jabber/auth.c   9d215cafa4b38a689d474feaf8cac54e8594da51
@@ -147,7 +147,7 @@ static int jabber_sasl_cb_simple(void *c
            *res = js->user->node;
            break;
        case SASL_CB_USER:
-           *res = "";
+           *res = js->user->node;
            break;
        default:
            return SASL_BADPARAM;

It's another workaround though, so I'm still not overly keen on the
idea, but it's less visible than an account preference.

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

It looks like #1 was addressed but not #2 or #3.

Regards,


Stu.

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel