[Patch] allow jabber users to avoid sasl authentication

[tom@…]

Hi,

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

[tom@…]

possibility to disable sasl for jabber

[tom@…]

To clarify, I checked out, changed, compiled and 'bzr diff'ed using 'bzr branch' on this url: ​http://code.bitlbee.org/bitlbee/

kind regeards, Tom Regner

[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

[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?

[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.

[wilmer]

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

[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

[wilmer]

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

[tom@…]

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

[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.

[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".

[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.

Thanks!

[tom@…]

allow disabling of sasl auth/ new flag SET_HIDDEN_DEFAULT

[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?

[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!

[tom@…]

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

[wilmer]

Submitted as changeset:devel,840. Thanks!