#863 closed enhancement (fixed)

[Patch] allow jabber users to avoid sasl authentication

Reported by: tom@… Owned by:
Priority: normal Milestone:
Component: BitlBee Version: devel
Keywords: jabber sasl Cc:
IRC client+version: Client-independent Operating System: Public server
OS version/distro: linux gentoo



I have the Problem that I need to use a xmpp-Server that is configured wrong. It advertises sasl-authentication mechanisms but freezes the connection if sasl authentication is tried. xmpp iq:auth works.

I found this out by comparing the tcp-dumps of a working client and bitlbee establishing connections.

I wrote a small addition to the jabber protocol that allows to "acc ID set sasl false" - if this is done, sasl authentication isn't even tried.

I advocate that change, with a default of 'sasl true', as it is not always possible to access the server in question.

I made this patch against the current bzr development branch.

Kind regards, Tom Regner

Attachments (2)

bitlbee-patch-jabber-sasl.patch (1.4 KB) - added by tom@… at 2011-11-17T14:38:44Z.
possibility to disable sasl for jabber
sasl_optional_HIDDEN_DEFAULT_flag.patch (2.9 KB) - added by tom@… at 2011-11-28T13:16:57Z.
allow disabling of sasl auth/ new flag SET_HIDDEN_DEFAULT

Download all attachments as: .zip

Change History (17)

Changed at 2011-11-17T14:38:44Z by tom@…

possibility to disable sasl for jabber

comment:1 Changed at 2011-11-18T04:58:05Z by tom@…

To clarify, I checked out, changed, compiled and 'bzr diff'ed using 'bzr branch' on this url:

kind regeards, Tom Regner

comment:2 Changed at 2011-11-20T16:18:53Z by tom@…

Hi again,

is there anything I can do to promote this proposed change?

I know this patch isn't the most sensible thing to do, considering best practices etc. But in spite of my findings, the internal ticket I opened with the guys running the xmpp-server in question, describing the problem and my solution was closed as "no solution possible".

So I either have to quit using bitlbee at work (not really an option) or patch it myself everytime you release another exciting update :-D -- since others in my working group consider switching to bitlbee with this patch included, if you would consider accepting this or another solution would be really helpful in the long run.

I don't want to be a pest about it, if your normal working schedule on bitlbee simply didn't allow you to react for now, please accept my appologies for writing too soon -- but I fear you are searching for a polite refusal.

Kind regards, Tom

comment:3 Changed at 2011-11-20T16:25:58Z by Wilmer van der Gaast <wilmer@…>

Yeah, sorry, I'm in Asia for a conference. I was wondering what to do with this though, actually just last week I was wondering if I should scrap support for non-SASL authentication.

IS this the only usable work-around? Do all clients still use 1999 Jabber authentication? Or is it more that BitlBee just doesn't support the required SASL method?

comment:4 Changed at 2011-11-21T07:13:02Z by tom@…

Bitlbee does supports both advertised sasl-authenticatoin mechanisms I think, PLAIN and DIGEST-MD5 IIRC. The Server (more likely the installation) is broken, but it won't get fixed in the foreseeable future.

comment:5 Changed at 2011-11-22T18:46:32Z by wilmer

And other clients also fail to fall back to non-SASL automatically and have a flag like this instead?

comment:6 Changed at 2011-11-22T22:05:25Z by tom@…

My old kopete (kde 3.5.x) does it without even trying sasl; the only known working client solution on linux for my colleages is the spark client, and quite frankly, that is not really an option -- another rather flamboyant solution employed by some is the installation of an openfire-server on the client machine -- connect with pidgin to the local server and let that one talk to the faulty one.

I understand your point -- maybe you can let the old xmpp:iq:auth live for a while as a compile-time option? another set of #ifdefs isn't pretty either, but I still hope that this will be sorted out by a server update...

If all this isn't an option, I'll patch my local installation following your development branch -- after all, this problem isn't common at all.

kind regards, Tom

comment:7 Changed at 2011-11-23T06:48:58Z by wilmer

Or just a hidden setting. I've been thinking about those for a while already. This bug report would serve as documentation.

comment:8 Changed at 2011-11-23T08:35:12Z by tom@…

A setting that doesn't show up on acc ID set, but is "setable"? I'd like that!

comment:9 Changed at 2011-11-24T07:41:22Z by wilmer

Cool. Yep, that was my idea. IIRC I already have that ability (set the SET_HIDDEN flag).

It may be sensible here to have a SET_HIDDEN_DEFAULT flag as well that will hide the setting unless it was changed from its default value. Sounds reasonable?

What I want to prevent is having tens of settings of which most are not ever going to be used by anyone. Call it my version of regedit. It'd also help if BitlBee had categories or some other kind of hierarchy to organise settings I guess.

comment:10 Changed at 2011-11-26T19:46:14Z by tom@…

Hmm - I would go as far as never showing these settings directly, even if changed -- I'd say a hidden setting is for the really advanced or really desperate users; hmm -- on the other hand, to receive a gazillion bug reports because people forgot they changed a hidden setting is also not cool... so, yeah, I like SET_HIDDEN_DEFAULT. Shall I take a look on the code and see if I can implement it reasonably well? Is there more to it than checking for the flag and the default value where the output for 'acc ID set' is assembled?

I don't know if a strict hierarchy is useful, strict meaning you have to use it anywhere. If settings were categorized, I'd wish for this hierarchy to be informational only -- used in building the listing for "acc ID set", but no needed on "acc ID set property value".

comment:11 Changed at 2011-11-26T23:07:33Z by Wilmer van der Gaast <wilmer@…>

Yup, like that. Similar to irssi. No real hierarchy and indeed still flat access, just categories to make it easier to find them.

And yes, please feel free to give SET_HIDDEN_DEFAULT a shot. It shouldn't actually be too hard to implement.


Changed at 2011-11-28T13:16:57Z by tom@…

allow disabling of sasl auth/ new flag SET_HIDDEN_DEFAULT

comment:12 Changed at 2011-11-30T11:32:39Z by tom@…

So - ist this small change ok? Can I cleanup the code and submit a final patch (at least fixing indentation if nothing else)? Or is it too simplistic?

comment:13 Changed at 2011-11-30T11:38:26Z by Wilmer van der Gaast <wilmer@…>

D'oh, I did not see that update. Trac doesn't normally send e-mail notifications for new attachments to bugs, but it looks like you did write a comment at the same time., :-/

The code looks good. Some indentation oddness (two spaces instead of tabs in some places) but I'll clean that up. Thanks!

comment:14 Changed at 2011-11-30T11:51:27Z by tom@…

Cool! No, I didn't comment -- I assumed an attachment would warrant an email :-)

comment:15 Changed at 2011-12-07T21:52:06Z by wilmer

Resolution: fixed
Status: newclosed

Submitted as changeset:devel,840. Thanks!

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.