Bug 217335

Created attachment 142158 [details]
Full gdb backtrace of the crash

gaim-debuginfo
cyrus-sasl-debuginfo

Please install these debuginfo packages then get another backtrace.

Created attachment 142216 [details]
Gaim2 beta5 crash - gdb backtrace with debug packages installed

Hello,

$ rpm -qv gaim-debuginfo cyrus-sasl-debuginfo 
gaim-debuginfo-2.0.0-0.22.beta5
cyrus-sasl-debuginfo-2.1.22-4

It appears that your gaim-debuginfo doesn't match the gaim package version?

Another question, if you "rpm -e cyrus-sasl-md5 --nodeps" then restart gaim,
does it work without crashing?

This appears to be a bug in either gaim or cyrus-sasl's md5 plugin.  Adding nalin.

Another question, what jabber server are you connecting to?  Is it available to
the public?

Hello,
(In reply to comment #5)
> Another question, what jabber server are you connecting to?  Is it available to
> the public?
Some of them are public; some of them are not.
I have an jabber.org account. Also there is a gmail.com account. In addition to
these, I have 4 other non-public OSS-related jabber servers.

Regards, Devrim

I use gmail.com jabber with seemingly no problem.

Could you please disable the various jabber accounts to see if any server in
particular triggers this problem?

Created attachment 142225 [details]
Gaim2 beta5 crash - gdb backtrace with debug packages installed #2

This is the new backtrace

Hello,

(In reply to comment #4)
> It appears that your gaim-debuginfo doesn't match the gaim package version?

I could find only beta3 debuginfo in repo. So, I built mine using the SRPM of
beta5. They should be identical. But it seems I used i386 gaim and i686
debuginfo. Ok, I attached another one again a few mins before.
 
> Another question, if you "rpm -e cyrus-sasl-md5 --nodeps" then restart gaim,
> does it work without crashing?

That made it. Gaim is running perfectly now.

> This appears to be a bug in either gaim or cyrus-sasl's md5 plugin.  Adding 
> nalin.

Thanks.

Regards, Devrim

gaim jabber cyrus-sasl-md5 crash

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400002
Equivalent bug at Debian

Could someone please find a public Jabber server that exhibits this problem?

BTW... I'm not sure but the crash may happen when we connect to the jabber
servers that we force old SSL. This may help you. 

Created attachment 142241 [details]
gaim-sasl-md5-crash.txt

gaim-2.0.0-0.22.beta5.fc6
cyrus-sasl-md5-2.1.22-4 (rebuilt with -O0)

Backtrace gives a little more detail.

The plugin is zeroing out the "clientout" and "clientoutlen" values passed in by
the calling application (see sasl_client_step(3) for more), but gaim is passing
in NULL for their locations.

I just made a change to Gaim SVN that should fix this.  Nalin, thanks for
digging through the backtrace for us.

Here's a diff:
http://svn.sourceforge.net/viewvc/gaim/trunk/libgaim/protocols/jabber/auth.c?r1=17834&r2=17833&view=patch&pathrev=17834

*** Bug 217026 has been marked as a duplicate of this bug. ***

ari wrote this patch that is a bit different for Debian.
http://svn.debian.org/wsvn/pkg-gnome/packages/unstable/gaim/debian/patches/09_jabber-sasl-crash.patch?op=file&rev=0&sc=0

Which solution is going to be upstream?

ari indicated that the upstream svn patch prevents the crash, but login does not
work.  ari's patch is uncertain to be correct either.  It would be very helpful
if a cyrus-sasl expert could look at this.

Warren, please remember that I don't have a server to test against here, either.
 In what way does login not work?  Do you mean authentication fails, or does
something go wrong immediately after authentication succeeds, or does this cause
a problem with the LOGIN mechanism?

I'm seeing the same behavior here when using old SSL.  To add to Warren's
comments, there is something else not quite right here with cyrus-sasl in
addition to what was fixed in the patch in comment #16 which causes gaim to no
longer segfault due to the NULL values.

For me, the login tries to proceed but gaim complains about an invalid response
from the jabber server.  I've attached the gaim debug output from a login
attempt, gaim_jabber_old_ssl_log.txt.

If need be, I can create some demo accounts on my jabber server for testing; I'm
running Wildfire 3.1.1.

Created attachment 142317 [details]
gaim jabber login transaction log

gaim has two different code paths for jabber authentication with either PLAIN or
MD5.  If gaim is built without cyrus-sasl, it uses an internal implementation
for PLAIN and MD5 which is known to work fine.  However, if you build with
cyrus-sasl, it only uses plugins that are installed for cyrus-sasl. 
cyrus-sasl-plain seems to work fine, as Fedora gaim has been using this for a
while now with cyrus-sasl-plain in a default install.  It seems that the other
methods like SASL MD5 never did work in gaim, and we haven't hit it often before
because nothing pulled in cyrus-sasl-md5 as a dependency.

SASL handling in gaim's jabber plugin seems to be either incomplete or just
plain wrong.  The challenge/response sequence when doing md5 is different than
the internal md5 implementation in gaim.  gaim upstream is not sure who wrote
this code, and nobody seems to understand cyrus-sasl in order to fix it with
certainty.

The simple workaround would be to disable building against cyrus-sasl, however
then we would lose the ability to use jabber with kerberos authentication.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

*** Bug 218061 has been marked as a duplicate of this bug. ***

For a Jabber server to test on - try talk.google.com.

faceprint upstream implemented a fix for this.  This is building in -0.26
currently.  We will be able to test it soon.

Fix is now in Fedora Core 6.

Works for me.

Great work!

QE ack for RHEL5.

A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.