Add OTR (off-the-record messaging) support to BitlBee

[anonymous]

Make BitlBee support OTR (off-the-record messaging: ​http://www.cypherpunks.ca/otr/).

This would allow people to have encrypted conversations with IMers. The connection between the IRC client and BitlBee would *not* be encrypted but this isn't always critical.

For example, I run BitlBee on my desktop and only connect to it via localhost. Then I use an Emacs IRC client (ERC) to connect to BitlBee and chat with my IMing friends. Before switching from Gaim to Emacs/ERC/BitlBee, my friends and I used OTR to encrypt our conversations.

The gaim-otr plugin's NEWS file and comments in lib-otr say that OTR can't work over IRC because IRC's maximum message size is too small.

Thanks!

[Jelmer Vernooij]

Isn't this a dupe of #44...?

[Jelmer Vernooij]

Now that BitlBee has plugin support, maybe this would be something that's nice to implement as a plugin?

I don't think functionality like this is likely to ever going to be part of the main bitlbee.

[happy@…]

I didn't see #44 before submitting--sorry. But my perspective is that OTR is the best option for adding encryption support to BitlBee--at least Gaim and Adium (on the Mac) support it.

[wilmer]

Well, since this is about OTR and #44 is about GPG, it's not a complete dupe. But it's certainly a wishlist bug. :-)

[hobart AT gmail]

Other users clients end up shoving spaces+tabs to attempt OTR initiation regardless, this comes thru ugly for the bee users :-) (see im-strangeness.png attachment)

[anonymous]

what other IM clients auto-attempting OTR initiation looks like to bitlbee users

[wilmer]

Ahh! I saw those in messages from a colleague too and I already wondered where they came from. They're indeed a bit annoying. :-(

[grey]

I second (third/fourth? Whatever) this. OTR support in bitlbee would be RAD!

[sia@…]

Another vote for OTR support in bitlbee!

--igor

[cenrim@…]

And another vote for OTR!

[micah@…]

and another

[tk]

vote

[anonymous]

Please add OTR! You would be the first CLI client to have support for it.

[anonymous]

i would use bitlbee if it had otr support

[anonymous]

vote too !

[onyx]

otr would be great, please add support :/

[anonymous]

i would definitely use bitlbee more with the encryption. in the world we live in today; you never know who is watching.

[ph]

please add otr support :(

[XTaran]

OTR support for Bitlbee indeed would be a cool feature.

[anonymous]

Replying to anonymous:

i would use bitlbee if it had otr support

same here. please add otr support

[anonymous]

agree!

[valentin.haenel@…]

OTR is supposed to be end 2 end. if you aren't using a bitlbee on localhost , its not really end 2 end.

If you can code c , you may be able to help us with:

​http://sourceforge.net/projects/otr-irssi/

cause we are way to busy with uni at the moment.

V-

[grey@…]

I had been begging Ian about OTR fragmentation support so that it could fit in an irc max message length. My friend Jake pestered him @ PET earlier this summer and he said he had an intern/student working on it.

Well, I just checked and it looks like it was finally added in libotr from the libotr-3.1.0 changelog!

"Large messages are now fragmented transparently instead of failing"

(and not to disrespect otr-irssi project, but I don't want to be tied to a particular IRC client, this was an OTR implementation flaw that was different in spec, but never implemented properly upstream by them)

w00t!

[M Spreij]

Blissfully ignorant of the technical details; would allowing bitlbee to connect through an OTR Proxy not be easier than implementing (plugin or no) it directly? Comments welcome at gmail.com@mspreij

[anonymous]

M Spreij - there is an OTR proxy from the OTR team already. It works with only /one/ IM protocol (AIM), and is a GUI program (BLARGH evil!), moreover getting it to work with Bitlbee, while doable (I've done it) is a bit of a pita - it will only work in one proxy mode (iirc http? not socks? I don't remember), and moreover when it does work it mangles buddy names (e.g. inserted extra spaces and stuff like that). It's basically a PoS and there's a reason why the otr staff haven't really devoted any development time to updating it.

However, you can use it today, with bitlbee - with the following caveats mentioned above (recap: runs as GUI, AIM only, only works in one proxy mode, mangles things that it shouldn't).

[pesco@…]

OTR support for BitlBee has been implemented, funded by stonedcoder.org. The bzr branch can be found at ​http://khjk.org/~pesco/bitlbee-otr/.

[anonymous]

This is great news!

Will this be merged into the main bitlbee code soon?

[anonymous]

Awesome! I've been waiting for this. :-)

[anonymous]

This is fantastic news, and what will get me using bitlbee. When can we expect this to be merged into the official releases?

[anonymous]

Does anybody know how to get the OTR code working with bitlbee? The documentation at khjk.org is rather sparse.

[anonymous]

"If you want to check out one of these branches, use bzr. Your web browser will just show empty directories, you have to use bzr to download the real code!"

bzr: ​http://www.bazaar-ng.org/

[anonymous]

I get randomly disconnected from AIM when this version of bitlbee receives some OTR messages. This is being caused by another person on my buddy list sending OTR messages that bitlbee is not expecting. Can you fix this?

I'm sorry I do not have more details, but I cannot reproduce it.

[ulim]

There is a functional irssi otr module now called irssi-otr of which I just released v0.1:

​http://projects.tuxfamily.org/group.pl?name=irssiotr

There's a git repo but you can also download a snapshot. Packages for various distros are underway.

Contact me on #bitlbee or by mail to irssiotr at tuxfamily.

[anonymous]

Awesome work ulim! Does it work with AIM/MSN/Yahoo/etc using bitlbee, or will it only work with IRC servers?

[Wilmer van der Gaast <wilmer@…>]

BitlBee wrote:

Awesome work ulim! Does it work with AIM/MSN/Yahoo/etc using bitlbee, or
will it only work with IRC servers?

It most definitely works with everything. If you find any issues, that's
a BitlBee bug (feel free to report, with enough debugging info).

[anonymous]

Replying to pesco@khjk.org:

OTR support for BitlBee has been implemented, funded by stonedcoder.org. The bzr branch can be found at ​http://khjk.org/~pesco/bitlbee-otr/.

works fine for me - good work :)

[pesco@…]

Seeing that some people are actually using my code, I've put up a little webpage describing how to get it via bzr, etc. There's also a snapshot-tarball for those reluctant to install yet another VCS. ;)

​http://khjk.org/bitlbee-otr/

Greets, pesco

[wahjava@…]

I've integrated pesco's bitlbee-otr code with bitlbee-1.2.3. The code is available at ​http://wahjava.googlepages.com/bitlbee-otr-1.2.3.tar.bz2 (md5: 089e2b3608673a00085283333d7cc32c).

Ashish Shukla

[pesco@…]

Hi, just to drop a note, I've finally come around to run another merge of the trunk into my branch, also integrating the previous updates from ashish. Please let me know of any issues!

pesco

[anonymous]

thanks pesco! your version works fine :D note: i had to install "xmlto" to get the compile to work (bzr version). i hope this gets merged into the official bitlbee. btw, when i did "otr smp <nickname> <secret>" the other user didnt receive the authorization request. instead i got: "smp: received abort from <nickname>". so to trust the user i had to manually enter his private key ("otr trust x x x x x"). he's using pidgin (v. 2.5.1) btw.

[ludo@…]

Is there any plan to merge bitlbee-otr into the main line?

Thanks, Ludo'.

[Kenyon Ralph <kenyon@…>]

I made a bitlbee-otr package for Ubuntu Karmic. It's on my Launchpad PPA for anyone to use: ​https://edge.launchpad.net/~kralph/+archive/ppa

[maci@…]

any news on this one?

[wahjava@…]

​Released BitlBee-OTR 1.2.5

[maci@…]

look nice so far a lot better than using irssi-otr. but still today, for no valid reason the bitlbee server seemed to have restarted i got reconnected and had to identify again.

had that once now, apart from that it looks stable and i'd like to see this upstream

[scott@…]

Why do people keep needing to hack this support in as a branch? Mainline it! I had been happily using a combination of BitlBee & ZNC until I ran into a few people I needed to talk to that require I use OTR. So I'm back to boring old Pidgin again. :-/

[wilmer]

Two things:

• I want to make this a plugin, there's no need to have it compiled in by default. BitlBee needs some additional hooks to allow this being a plugin. I hope to add these soon and then I may include the OTR module with the BitlBee source tree by default (not sure yet though, once it's a plugin it'll also be a lot less painful to maintain it separately).
• bitlbee-otr is not properly end-to-end. Proper crypto should be. Now usually BitlBee and the IRC client run on the same host, but not always. bitlbee-otr could give a bit of a false sense of security.

You don't use irssi/xchat? There are native OTR plugins for those two AFAIK. maci, what's your problem with irssi-otr, I wonder?

[scott@…]

Replying to wilmer:

• I want to make this a plugin, there's no need to have it compiled in by default. BitlBee needs some additional hooks to allow this being a plugin. I hope to add these soon and then I may include the OTR module with the BitlBee source tree by default (not sure yet though, once it's a plugin it'll also be a lot less painful to maintain it separately).

That sounds great!

• bitlbee-otr is not properly end-to-end. Proper crypto should be. Now usually BitlBee and the IRC client run on the same host, but not always. bitlbee-otr could give a bit of a false sense of security.

I realize that, and it's a very good point. We're more concerned about his end than mine. Anything is better than nothing. There should be some kind of warning though so people understand what is going on.

You don't use irssi/xchat? There are native OTR plugins for those two AFAIK. maci, what's your problem with irssi-otr, I wonder?

I can't always. Sometimes I'm stuck on my phone. :-/

[micah anderson <micah@…>]

You don't use irssi/xchat? There are native OTR plugins for those two
AFAIK. maci, what's your problem with irssi-otr, I wonder?

I use irssi, the otr plugin to irssi is pretty bad, it segfaults the
entire irssi session, and gets desync'd often. It makes me sad.

[maci@…]

no segfaults here but the desync is really annoying. it also messes up html stripping and some other things

[Wilmer van der Gaast <wilmer@…>]

no segfaults here but the desync is really annoying. it also messes up
html stripping and some other things

Ouch. That sounds problematic. Also sounds like the HTML stripping
should be moved from BitlBee to the IRC client in those cases.

Still, I'll try to make this pluginable. All it needs is hooks for
incoming and outgoing messages, and allowing plugins to add root
commands. (I think.)

[maci@…]

Ouch. That sounds problematic. Also sounds like the HTML stripping

should be moved from BitlBee to the IRC client in those cases.

Yeah, im already using irssi triggers to strip the html, but it still fucks up sometimes

• bitlbee-otr is not properly end-to-end. Proper crypto should be. Now usually BitlBee and the IRC client run on the same host, but not always. bitlbee-otr could give a bit of a false sense of security.

are you sure irssi is really the end?

it might be running on another box as well, just like bitlbee.

example: im running irssi in screen on a remote sever. i connect to that server using telnet/rlogin

now its not end-2-end either ;)

[ilf@…]

Just a "me too" comment to be subscribed :)

irssi-otr is really annoying me for the above reasons and bitlbee-otr hasn't been touched since 1.2.5 in March :(

[Wilmer van der Gaast <wilmer@…>]

Where is this branch again?

I expect that 1.2.5->1.2.7 won't be a horrible merge conflict (if problematic at all). If it's still a nice bzr branch somewhere I'm willing to maintain it myself to just keep it in sync with head.

[ilf]

Wilmer: ​http://khjk.org/bitlbee-otr/

bzr checkout ​http://code.khjk.org/bitlbee-otr

[anonymous]

Also, there is an Ubuntu package of bitlbee-otr 1.2.6a at ​https://edge.launchpad.net/~kralph/+archive/ppa/+packages

The packaging is in a bzr branch too: ​http://kenyonralph.com/pkg-bitlbee-otr/bitlbee-otr

[Sven Moritz Hallberg <pesco@…>]

Replying to ilf:

bzr checkout ​http://code.khjk.org/bitlbee-otr/

Just updated to 1.2.6 and it seems to run fine. More testing appreciated.

Replying to Wilmer van der Gaast <wilmer@…>:

I expect that 1.2.5->1.2.7 won't be a horrible merge conflict (if problematic at all).

Actually, there's a slight logic conflict in 1.2.7 where you added support for showing offline buddies. I had changed the way settings control who gets voice/op flags etc. to accomodate for the possibility of showing OTR status with them.

Unfortunately I don't have a lot of brain cycles at this moment to think about it, though I expect there exists a clean solution that integrates both things. Feel free to have a look.

If it's still a nice bzr branch somewhere I'm willing to maintain it myself to just keep it in sync with head.

It would be nice if we could maintain it on bitlbee.org, ideally with multiple people with commit access, because right now, I'm the bottleneck.

On a side note, if you (anyone) do the work of merging to a new version, and want me to integrate it into the branch on khjk.org, please send a PATCH by means of 'bzr send'! A packaged tarball is next to useless to me, because there's no way to see whether and how any conflicts were resolved.

[wahjava@…]

I've merged Sven's code into bitlbee and released[1] bitlbee-otr. Its latest versions are available[2] in FreeBSD.

References: [1] ​http://wahjava.wordpress.com/tag/bitlbee-otr/ [2] ​http://freshports.org/irc/bitlbee-otr/

Ashish

[wilmer]

Hey Pesco, I'm glad to see you here. Yeah, I don't mind keeping bitlbee-otr up to date myself when I break compatibility. Shouldn't happen *that* often. The show_offline stuff indeed caused some troubles then, and I vote for leaving it like that for just another bit. With the rewritten IRC core we can hopefully come up with a more proper fix for this.

wahjava, do you have a bzr branch of that?

[wahjava@…]

No, I use git. It is hosted on github at following link:

​http://github.com/abbe/bitlbee-otr

master branch contains the bitlbee-otr source code, and bitlbee branch contains bitlbee source code.

[Sven Moritz Hallberg <pesco@…>]

So, I've pulled the khjk branch up to latest HEAD.

I think the show_offline issue resolved itself relatively easy in my branch, precisely because of the way I changed the voice/op handling around: I have separate settings (voice|halfop|op)_buddies with possible values false|online|notaway|encrypted|trusted. Of these, only online is new. So if you turn on show_offline you have to set something like voice_buddies=online and op_buddies=notaway to get the behaviour of HEAD. I've documented this in the user guide.

Wilmer, can you see in the code how I did it (function imcb_buddy_status in protocol/nogaim.c)?

One new thing I've added: Twitter is not a protocol where OTR is applicable. Therefore, the OTR subsystem should be disabled on twitter accounts. I've added a constant OPT_NOOTR which gets set in the struct prpl options field of the twitter protocol. The OTR subsystem checks for this on entry to message and key handling functions and falls back to non-OTR behaviour if the flag is set. Is this the way it should be done?

Ashish, did you make any functional changes in your branch that I might have missed?

As before, testing appreciated!

[wahjava@…]

Replying to Sven Moritz Hallberg <pesco@…>: [...]

Ashish, did you make any functional changes in your branch that I might have missed?

Nop. I just merged the conflicts.

[ilf]

Good stuff going on here.

What about the plan to make otr a plugin for bitlbee, so we don't have to maintain an entire fork?

[Sven Moritz Hallberg <pesco@…>]

Replying to ilf:

What about the plan to make otr a plugin for bitlbee, so we don't have to maintain an entire fork?

I have to say, though I don't want to get into a fight about it, I still don't see why the code should not be merged into mainline even before it can be a plugin.

• It is not a strict dependency. If there is no libotr, it won't be built and the hook calls are turned into preprocessor-macros that expand to the original non-OTR code.
• A package maintainer can avoid depending on libotr by disabling it. This is no worse than currently.
• An alternative bitlbee-otr package can be trivially built from the same source by flipping the switch the other way. This is preferable to the current situation.
• It can be turned into a run-time plugin as soon as that becomes feasable.
• Wilmer has stated that maintening the additional code won't be a problem.

Personally, I would even argue for pre-built packages to include OTR support (and depend on libotr), on the assumption that it is desirable to have encryption available by default, but that is a secondary issue.

[Wilmer van der Gaast <wilmer@…>]

Hey,

Generally, I agree, but I'd really prefer having a plugin mostly *for*
packaging reasons. Having a small plugin module one can install next to
BitlBee itself would be a lot nicer than having an alternative package.

Probably the configure script would get three options then: Don't build
OTR, statically link it with BitlBee or have it as a separate
dynamically loadable module.

Personally, I would even argue for pre-built packages to include OTR
support (and depend on libotr), on the assumption that it is desirable to
have encryption available by default, but that is a secondary issue.

I'm a bit on the fence about this. For most of my IM communication I'm
not very concerned about the security and many people aren't. Also I
don't see a lot of OTR users around me anymore lately.

OTOH, I don't want to be on the counter-productive side of a chicken-egg
problem. So the latter is not an argument. :-)

Since I won't be using this myself a whole lot (I don't think any of my
contacts has OTR in their client) I hope you and others will have time
to keep the OTR-specific bits up-to-date though.

The problems with HTML/multiline messages convinced me that there is a
place for OTR in BitlBee (even though it's not as end-to-end as one
would ideally want to have), so I'll find a way to merge this that will
make/keep everyone happy. :-)

[ilf]

Yay. When this gets mainline, just add us and you'll use a lot of OTR :)

Seriously, people will start using it, when stuff works "out of the box". More work, less users.

You're right about it not being fully End-To-End for people not running their own BitlBee on the same box as their own IRC client. I think this should be noted in README.

[ilf]

Thanks. Using 1.2.7 OTR on one box now.

Unfortunately, $strip_html does not work with OTR for me.

Is that code section called before OTR decryption?

[Kenyon Ralph <kenyon@…>]

Re: ilf's comment about $strip_html and OTR: I have a patch for that in my Ubuntu package. See ​https://edge.launchpad.net/~kralph/+archive/ppa/+packages or bzr checkout ​http://kenyonralph.com/pkg-bitlbee-otr/bitlbee-otr

If you're talking to someone using Adium, there is a bug about it: ​http://trac.adium.im/ticket/6901

[Kenyon Ralph <kenyon@…>]

Re: my previous comment. Here is the patch I use. It may not be the correct solution, but it does what I want. ​http://kenyonralph.com/adium-otr-html.diff or ​http://paste.pocoo.org/show/223146/

[Sven Moritz Hallberg <pesco@…>]

Updated to upstream 1.2.8.

[wilmer]

Thanks for the update! Have you by any chance tried to update it to the ui-fix codebase? I'm planning to do it myself when all the other work on it is done (which is going to be fairly soon), and then eventually merging it.

[wilmer]

Hmm. So we have two versions of bitlbee-otr now, and they're slightly different. :-/

wilmer@peer:~/src/bitlbee/otr$ diff -ur bitlbee-otr* | diffstat
 bitlbee-otr-1.2.8/bitlbee.conf                   |    4 
 bitlbee-otr-1.2.8/bitlbee.h                      |    7 
 bitlbee-otr-1.2.8/configure                      |   24 +
 bitlbee-otr-1.2.8/doc/bitlbee.8                  |    2 
 bitlbee-otr-1.2.8/doc/bitlbee.xinetd             |    5 
 bitlbee-otr-1.2.8/doc/user-guide/commands.xml    |  140 ++++-------
 bitlbee-otr-1.2.8/irc.c                          |   21 -
 bitlbee-otr-1.2.8/lib/misc.c                     |   22 -
 bitlbee-otr-1.2.8/lib/ssl_sspi.c                 |  278 -----------------------
 bitlbee-otr-1.2.8/motd.txt                       |    6 
 bitlbee-otr-1.2.8/otr.c                          |   24 -
 bitlbee-otr-1.2.8/protocols/nogaim.c             |  113 +++++++--
 bitlbee-otr-1.2.8/protocols/nogaim.h             |   10 
 bitlbee-otr-1.2.8/protocols/twitter/twitter.c    |    1 
 bitlbee-otr-1.2.8/set.c                          |    2 
 bitlbee-otr-1.2.8/storage.c                      |    1 
 bitlbee-otr-1.2.8/storage_xml.c                  |    5 
 bitlbee-otr-1.2.8/unix.c                         |    2 
 26 files changed, 213 insertions(+), 454 deletions(-)

What I'll probably end up doing is do a merge but revert pretty much everything except otr.[ch] (the rest won't apply cleanly anyway with the IRC core rewrite), and then figure out how to glue it all together again. :-)

Which one has more users, how did this evolve?

[anonymous]

Working on this merge now: ​http://code.bitlbee.org/wilmer/merging-otr/

Note that this is not very functional yet. It loads, the otr root command works, you can generate keys ... but I have to add hooks for incoming/outgoing msgs, restore channel modes in a more ui-fix-compatible way, and who knows what else.

I assume/hope I can still count on you guys to maintain this once I finish the merge?

[pesco@…]

Replying to wilmer:

Hmm. So we have two versions of bitlbee-otr now, and they're slightly different. :-/

..

What I'll probably end up doing is do a merge but revert pretty much everything except otr.[ch] (the rest won't apply cleanly anyway with the IRC core rewrite), and then figure out how to glue it all together again. :-)

This is reasonable, as otr.[ch] was designed to contain all the actual code that just needs to be hooked into the right places (an init here, a hook there, ...)

Which one has more users, how did this evolve?

It probably happened due to me not being quick enough with the updates (my fault) and whoever took the work into their own hands (good!) not sending a patch back.

Replying to anonymous:

Note that this is not very functional yet. It loads, the otr root command works, you can generate keys ... but I have to add hooks for incoming/outgoing msgs, restore channel modes in a more ui-fix-compatible way, and who knows what else.

Once you've hooked into the msg I/O, that should be it pretty much...

I assume/hope I can still count on you guys to maintain this once I finish the merge?

Put it in mainline and I'll be all over it. ;P

[Wilmer van der Gaast <wilmer@…>]

This is reasonable, as otr.[ch] was designed to contain all the actual
code that just needs to be hooked into the right places (an init here, a
hook there, ...)

Exactly. I saw that, and I really like it. :-) This merge been pretty
easy so far, and lets me add some plugin hooks that will be useful for
other things as well (if anything else ever comes up).

Once you've hooked into the msg I/O, that should be it pretty much...

That's what I thought, and I'm close enough. It'd be nice to port the
mode stuff in a sane way as well though.

Put it in mainline and I'll be all over it. ;P

Deal[[BR]]

[pesco@…]

Replying to Wilmer van der Gaast <wilmer@…>:

Once you've hooked into the msg I/O, that should be it pretty much...

That's what I thought, and I'm close enough. It'd be nice to port the mode stuff in a sane way as well though.

Yah. I realize I invaded on the turf of UI design a little when I changed those settings around. Take it as inspiration and do what suits you best. Organizing the settings as a map "channel mode->condition that triggers it" rather than multiple flags with complicated interactions seemed a) clean to implement and b) to clearly convey to the user what his settings mean.

Put it in mainline and I'll be all over it. ;P

Deal!

:) I'll have a look over the new codebase then.

[Wilmer van der Gaast <wilmer@…>]

16:29:53 @   wilmer| help set show_users
16:29:53 @     root| Type: string
16:29:53 @     root| Scope: channel
16:29:53 @     root| Default: online+,away
16:29:53 @     root|  
16:29:53 @     root| Comma-separated list of statuses of users you 
                     want in the channel, and any modes they should 
                     have. The following statuses are currently 
                     recognised: online (i.e. available, not away), 
                     away, and offline.
16:29:53 @     root|  
16:29:53 @     root| If a status is followed by a valid channel 
                     mode character (@, % or +), it will be given 
                     to users with that status. For example, 
                     online@,away+,offline will show all users in 
                     the channel. Online people will have +o, 
                     people who are online but away will have +v, 
                     and others will have no special modes.

That's what we have now. I'll see about either integrating OTR into this same var, or about making a separate otr_modes setting that can override modes if the user wants.

[wilmer]

I got something usable now. changeset:merging-otr,675.

SMP doesn't seem to work but I've only tried it with Pidgin on the other side, and in my tests I don't even see a response coming back in tcpdump. So I don't know where this is.

pesco, would you have time to see what's going on with that?

I've also found one bug causing crashes at disconnect time if keys were generated, since the FILE*s weren't reset to NULL after closing them.

[wilmer]

Will you have time to look at the SMP issues soonish? I'd like to get that fixed, and probably once that's done this is merge-worthy. I'll work on making this a full proper loadable plugin at some later point.

[pesco@…]

Replying to wilmer:

Will you have time to look at the SMP issues soonish? I'd like to get that fixed, and probably once that's done this is merge-worthy. I'll work on making this a full proper loadable plugin at some later point.

Huh, I had replied already Friday, but appearently it got stuck somewhere on the interwebs. I was on vacation over the weekend but I've got it on the TODO list for this week!

[pesco@…]

Replying to wilmer:

I got something usable now. changeset:merging-otr,675.

SMP doesn't seem to work but I've only tried it with Pidgin on the other side, and in my tests I don't even see a response coming back in tcpdump. So I don't know where this is.

It works fine between my two BitlBee instances (merging-otr and 1.2.8). But with another user on Pidgin, I stumbled across this: Pidgin has a "question/answer" kind of interface for SMP. I had always assumed this was just fancy optics because there is no "question" in the protocol. It looks like that might not be the whole story:

• Case 1: Pidgin initiates SMP.
  • Pidgin sends a request, question "foo", answer "bar".
  • BitlBee shows nothing.
  • I type otr smp <nick> bar.
  • BitlBee reports smp: responding to <nick>...
  • BitlBee reports smp <nick>: secrets did not match, fingerprint not trusted.
  • Pidgin reports success (sic).
• Case 2: BitlBee initiates SMP.
  • I type otr smp <nick> bar.
  • BitlBee reports smp: initiating with <nick>...
  • Other user gets a plain dialog asking for the "secret" (not "answer", no question is displayed).
  • Other user enters "bar".
  • BitlBee reports smp <nick>: secrets proved equal, fingerprint trusted.

So appearently they've introduced some new protocol message(s) to represent the Q/A type interface. Support for these must be added to the code to make case 1 work.

Not sure if this is what you were seeing though, if you had no answer at all. I'll give it another whirl with the Pidgin I have at work tomorrow.

[pesco@…]

Replying to pesco@…:

So appearently they've introduced some new protocol message(s) to represent the Q/A type interface. Support for these must be added to the code to make case 1 work.

Not sure if this is what you were seeing though, if you had no answer at all. I'll give it another whirl with the Pidgin I have at work tomorrow.

Indeed, libotr appearently supports the "question and answer" method with new packets, which I'll have to add support for. Shouldn't be too much work, I'll give it a kick on the weekend.

Nevertheless, the old method is still available in Pidgin by choosing "shared secret" from the authentication dialog. Also, initiating the old protocol from the BitlBee side should just work, as described in case 2 above.

Wilmer, can you try again whether pidgin "shared secret" to bitlbee works for you? And bitlbee (old-style) to pidgin? Thanks!

[pesco@…]

I've implemented Q&A-style SMP support, incoming as well as outgoing. The latter gets a new command otr smpq <nick> <question> <answer>. I've tested it with my old BitlBee and an up-to-date Pidgin.

I wanted to attach the patch bundle to this ticket but unfortunately, the word "Social*st" contains "cial*s", and it was rejected for spam. ;) I've put it up for the moment at ​http://khjk.org/~pesco/merging-otr-pesco-676-683.bundle .

[wilmer]

Merged, now let me try again how it works for me.

BTW I just noticed you assigned copyrights on otr.c to me. Feel free to claim those, you wrote 99% of that file after all.

[wilmer]

Doing smpq from Pidgin to BitlBee still looks to me like case 1:

23:13:48 <@root> smp wilm0r: secrets did not match, fingerprint not trusted

I tried it twice, the answer was definitely correct. And if I screw up the answer, Pidgin does report failure.

Initiating this from BitlBee works properly though, awesome! So this is merged now, and also since changeset:merging-otr,676 it can be built as a run-time plugin. This makes packaging this trivial!

[anonymous]

Replying to wilmer:

Doing smpq from Pidgin to BitlBee still looks to me like case 1:

23:13:48 <@root> smp wilm0r: secrets did not match, fingerprint not trusted

I tried it twice, the answer was definitely correct. And if I screw up the answer, Pidgin does report failure.

Confirmed. I have a suspicion what's causing this. Will have a look at it on the weekend!

[pesco@…]

Got it: It appears libotr (3.2.0) forgets to set the trust value when responding to an smpq request! Here's a new patch bundle for you: ​http://khjk.org/~pesco/merging-otr-pesco-679-683.bundle

Testing appreciated, I'll give it another round as well tomorrow.

Oh, and I've clarified the copyright note. ;)

[wilmer]

Great! I merged it into merging-otr. Will merge it into mainline in another few days.

[pesco@…]

Awesome. As by my tests, everything seems to work fine with otr smpq now.

So the last major TODO left from my point of view is to support flagging encrypted/trusted connections with voice/ops/halfops. have you got any more thoughts on that?

[pesco@…]

Soo... it turns out I was a little bit mistaken there:

I asked on the otr-dev mailinglist and the underlying behaviour of "case 1" above is what is intended in "q&a" style SMP. Only the party that asks the question gets their trust set, the responder's value is not touched. Therefore, since the old code checked the trust value to detect success or failure, it would always report whatever was set initially! And revision 678 was actually acting correctly, just making misleading comments about it. ;)

Whatever, here's your patch: ​http://khjk.org/~pesco/merging-otr-pesco-680.bundle

It removes the faulty workaround from previously, adds specific messages for the q&a response case, and updates the command help.

[wilmer]

Alright, merged.

Yes, there's that last one TODO. I'm thinking of *not* blocking the merge into mainline (plus the next major release) on that, what do you think?

[pesco@…]

Fine by me. This is not a show-stopper, just a nice-to-have.

For the future after the merge, what will be the prefered way to submit patches?

[wilmer]

changeset:devel,699

MERGED!

I also tweaked the Debian pkg stuff to automatically build a bitlbee-plugin-otr package.

I should get you an account on code.bitlbee.org probably so you can push new stuff there in code.b.o/pesco/otr/ or sometihng.