On May 3, 2010, at 3:49 PM, Joe Hildebrand wrote:
> This *almost* works. The error is now correct, but we shouldn't
> auto-reconnect if the password was bad.
I agree; however, code is already in place which should be handling that.
Please post debug logging of sending an incorrect password and not getting
prompted to enter a correct one.
-Evan
>
>
> On 5/3/10 2:30 PM, "Evan Schoenberg, M.D." <e...@adium.im> wrote:
>
>>
>> On May 3, 2010, at 11:42 AM, David Smith wrote:
>>
>>> I'd be happy to check if I can still connect to iChat Server if someone
>>> gives
>>> me a patched Adium.
>>
>>
>> I should have checked the code instead of the ticket; I left later-me some
>> good details there.
>> jabber_auth_start_cyrus() for us includes:
>> {
>> /* We have no mechs which can work.
>> * Try falling back on the old jabber:iq:auth method. We get here if the
>> server
>> supports
>> * one or more sasl mechs, we are compiled with cyrus-sasl support, but we
>> support or can connect with none of
>> * the offerred mechs. jabberd 2.0 w/ SASL and Apple's iChat Server 10.5 both
>> handle and expect
>> * jabber:iq:auth in this situation. iChat Server in particular offers SASL
>> GSSAPI by default, which is often
>> * not configured on the client side, and expects a fallback to jabber:iq:auth
>> when it (predictably) fails.
>> *
>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is
>> wrong. However,
>> * I believe this refers to actual authentication failure, not a simple lack
>> of
>> concordant mechanisms.
>> * Doing otherwise means that simply compiling with SASL support renders the
>> client unable to connect to servers
>> * which would connect without issue otherwise. -evands
>> */
>> js->auth_mech = NULL;
>> jabber_auth_start_old(js);
>> return JABBER_SASL_STATE_CONTINUE;
>> }
>>
>>
>> However, elsewhere in auth_cyrus, jabber_cyrus_handle_failure() has what
>> appears to be better logic:
>>
>> if (tried_gssapi_first) {
>> /* If we tried GSSAPI first, it failed, and it was our only shot, try
>> jabber:iq:auth
>> * for compatibility with iChat 10.5 Server.
>> *
>> * iChat Server 10.5 offers SASL GSSAPI by default, which is often
>> * not configured on the client side, and expects a fallback to jabber:iq:auth
>> when it (predictably) fails.
>> *
>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is
>> wrong. However,
>> * I believe this refers to actual authentication failure, not a simple lack
>> of
>> concordant mechanisms.
>> * Doing otherwise means that simply compiling with SASL support renders the
>> client unable to connect to servers
>> * which would connect without issue otherwise. -evands
>> */
>> sasl_dispose(&js->sasl);
>> js->sasl = NULL;
>> js->auth_mech = NULL;
>> jabber_auth_start_old(js);
>> return JABBER_SASL_STATE_CONTINUE;
>> }
>>
>> (comments expanded just-now by me).
>> In im.pigin.adium.1-4's 2fcd834324b05d3becf6878db8ce1c474578e720 I have
>> removed the former, aggressive behavior and left the latter. I think this
>> should solve the problem presented while maintaining the workaround for iChat
>> Server 10.5's apparent wrongness.
>>
>>
>> This is committed in adium-1.4's [6534647aece5289a0e5ac90c012bcbf75e3918f3].
>>
>> A build for testing is uploaded at
>> http://adiumx.cachefly.net/Adium_1.4b18-noJabberHack.dmg
>>
>> The downgrade attack Joe mentions does still exist, but now if and only if
>> ((GSSAPI is the only offered SASL mech) && (GSSAPI fails)). Further
>> improvement would be a prompt as described in that setting; patches welcome.
>>
>> Look forward to any feedback.
>>
>> -Evan
>
> --
> Joe Hildebrand
>
>
