This *almost* works. The error is now correct, but we shouldn't auto-reconnect if the password was bad.
On 5/3/10 2:30 PM, "Evan Schoenberg, M.D." <[email protected]> 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
