[Adium-devl] [Adium-svn] rev 21712 - in trunk: Frameworks/libpurple.framework/Versions/0.3.0 Frameworks/libpurple.framework/Versions/0.3.0/Headers Plugins/Purple Service Utilities/dep-build-scripts

[Evan Schoenberg]

On Nov 22, 2007, at 1:25 AM, Peter Hosey wrote:

> On Nov 21, 2007, at 21:23:35, evands at adiumx.com wrote:
>> We only set this to TRUE if the client is running on 10.4, where  
>> PLAIN cyrus-sasl fails authentication because the username is  
>> mysteriously doubled before Base64 encoding is performed.
>
> Can you be more specific about the nature of this “doubling”?

In the thread entitled "[Adium-devl] libsasl (commits 21692 and  
21697)", I wrote:
  * When it fails, it's with the PLAIN sasl authentication method.
PLAIN simply does a Base64 encoding of the username and password, e.g.
'evanpassword' for a username of evan.  In the failing 10.4 systems,
the same username and password become 'evanevanpassword' (the username
is repeated), and the result is Base64 encoded. This, of course, fails
to authenticate.

> And have we confirmed that it happens in the library, or could it be  
> a bug in libpurple's use of it?
Libpurple registers some callbacks in auth.c with libsasl. One  
provides the username for the login process; another provides the  
password.  These callbacks are generic, independent of the auth scheme  
which will be used. sasl collects the data it needs, does what  
encrypting (or not) is appropriate for the scheme, and then passes the  
result back to the client (libpurple) for use.

As far as I could tell when I had a 10.4 machine and was testing it  
(when we were initially setting up cyrus-sasl in the old  
Libpurple.framework build system), each callback was called only once,  
yet when sasl passed back the data to be sent over the wire it was as  
above.

This occurred in 10.4 when we just linked against libsasl.dylib  
initially.  This was resolved for 10.4 and 10.5 by doing a static  
compilation of cyrus-sasl which included all the needed plugins  
(statically) and linked statically into Libpurple.framework.  That, of  
course, is ugly... also, it can't be done by the native build system  
so far as I can tell.  It was only possible because we had usurped the  
build system and made a giant Frankenstein-esque xcode project for  
libpurple and all dependencies.

The problem returned, looking the same, when we went to the new build  
system.

With a single binary, it happens in 10.4 but not 10.5, and I can't  
find reports of it happening in any other build environment.  I think  
it is either the result of a problem with the build of libsasl -or- of  
its PLAIN authorization plugin on 10.4.  I am, of course, open to  
other theories :)

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20071122/3f4aaba3/attachment-0001.html>