Modify

#115 closed enhancement (fixed)

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

Reported by: anonymous Owned by:
Priority: wishlist Milestone:
Component: BitlBee Version: 1.0.1
Keywords: Cc: happy@…
IRC client+version: Client-independent Operating System: Public server
OS version/distro:

Description

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!

Attachments (1)

im-strangeness.png (20.3 KB) - added by anonymous at 2006-06-18T19:30:20Z.
what other IM clients auto-attempting OTR initiation looks like to bitlbee users

Download all attachments as: .zip

Change History (93)

comment:1 Changed at 2006-03-14T00:47:24Z by Jelmer Vernooij

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

comment:2 Changed at 2006-03-14T00:54:24Z by 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.

comment:3 Changed at 2006-03-14T01:00:17Z by 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.

comment:4 Changed at 2006-03-18T09:16:59Z by wilmer

Priority: normalwishlist

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

comment:5 Changed at 2006-06-18T19:29:42Z by 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)

Changed at 2006-06-18T19:30:20Z by anonymous

Attachment: im-strangeness.png added

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

comment:6 Changed at 2006-06-18T19:32:57Z by 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. :-(

comment:7 Changed at 2006-10-26T17:54:02Z by grey

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

comment:8 Changed at 2007-03-08T07:54:16Z by sia@…

Another vote for OTR support in bitlbee!

--igor

comment:9 Changed at 2007-03-14T14:56:21Z by cenrim@…

And another vote for OTR!

comment:10 Changed at 2007-03-27T04:27:28Z by micah@…

and another

comment:11 Changed at 2007-05-30T15:40:06Z by tk

vote

comment:12 Changed at 2007-06-09T12:46:45Z by anonymous

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

comment:13 Changed at 2007-07-09T21:52:48Z by anonymous

i would use bitlbee if it had otr support

comment:14 Changed at 2007-07-10T18:12:41Z by anonymous

vote too !

comment:15 Changed at 2007-07-19T13:30:30Z by onyx

otr would be great, please add support :/

comment:16 Changed at 2007-07-20T21:02:02Z by anonymous

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

comment:17 Changed at 2007-07-25T18:37:48Z by ph

please add otr support :(

comment:18 Changed at 2007-08-19T15:08:29Z by XTaran

OTR support for Bitlbee indeed would be a cool feature.

comment:19 in reply to:  13 Changed at 2007-09-30T15:47:18Z by anonymous

Replying to anonymous:

i would use bitlbee if it had otr support

same here. please add otr support

comment:20 Changed at 2007-10-26T17:28:29Z by anonymous

agree!

comment:21 Changed at 2007-11-09T15:08:13Z by 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-

comment:22 Changed at 2007-11-28T00:31:11Z by 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!

comment:23 Changed at 2007-12-05T12:10:18Z by 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

comment:24 Changed at 2007-12-05T20:53:45Z by 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).

comment:25 Changed at 2008-02-19T01:39:49Z by 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/.

comment:26 Changed at 2008-02-19T16:05:41Z by anonymous

This is great news!

Will this be merged into the main bitlbee code soon?

comment:27 Changed at 2008-04-09T18:56:32Z by anonymous

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

comment:28 Changed at 2008-04-14T00:38:50Z by anonymous

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

comment:29 Changed at 2008-05-14T14:42:55Z by anonymous

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

comment:30 Changed at 2008-05-14T14:58:15Z by 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/

comment:31 Changed at 2008-05-28T20:51:21Z by 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.

comment:32 Changed at 2008-06-18T11:00:56Z by 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.

comment:33 Changed at 2008-06-19T01:00:38Z by anonymous

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

comment:34 Changed at 2008-06-19T07:53:24Z by 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).

comment:35 in reply to:  25 Changed at 2008-07-13T02:58:46Z by 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 :)

comment:36 Changed at 2008-07-17T08:50:18Z by 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

comment:37 Changed at 2008-11-16T03:56:37Z by 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

comment:38 Changed at 2009-03-13T13:19:14Z by 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

comment:39 Changed at 2009-03-28T21:45:06Z by 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.

comment:40 in reply to:  38 Changed at 2009-07-10T07:28:50Z by ludo@…

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

Thanks, Ludo'.

comment:41 Changed at 2009-12-28T11:03:06Z by 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

comment:42 Changed at 2010-04-18T08:57:21Z by maci@…

any news on this one?

comment:44 Changed at 2010-04-19T09:43:08Z by 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

comment:45 Changed at 2010-04-21T18:10:07Z by 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. :-/

comment:46 Changed at 2010-04-21T23:34:03Z by 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?

comment:47 in reply to:  46 Changed at 2010-04-21T23:46:24Z by 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. :-/

comment:48 Changed at 2010-04-22T02:47:31Z by 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.

comment:49 Changed at 2010-04-22T07:13:31Z by maci@…

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

comment:50 Changed at 2010-04-22T08:41:48Z by 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.)

comment:51 in reply to:  46 Changed at 2010-04-22T11:21:30Z by 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 ;)

comment:52 Changed at 2010-06-03T10:03:06Z by 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 :(

comment:53 Changed at 2010-06-03T10:08:15Z by 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.

comment:55 Changed at 2010-06-03T10:45:16Z by 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

comment:56 in reply to:  53 Changed at 2010-06-03T11:42:38Z by 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.

comment:57 Changed at 2010-06-03T16:32:29Z by 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

comment:58 Changed at 2010-06-03T21:08:47Z by 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?

comment:59 Changed at 2010-06-03T21:25:37Z by 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.

comment:60 Changed at 2010-06-03T22:37:02Z by 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!

comment:61 in reply to:  60 Changed at 2010-06-03T22:39:11Z by 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.

comment:62 Changed at 2010-06-04T07:44:35Z by 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?

comment:63 in reply to:  62 Changed at 2010-06-04T12:42:20Z by 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.

comment:64 Changed at 2010-06-04T13:55:34Z by 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. :-)

comment:65 Changed at 2010-06-04T14:10:40Z by 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.

comment:66 Changed at 2010-06-07T20:49:49Z by 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?

comment:67 Changed at 2010-06-07T21:39:10Z by 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

comment:68 Changed at 2010-06-08T09:48:43Z by 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/

comment:69 Changed at 2010-07-11T17:33:58Z by Sven Moritz Hallberg <pesco@…>

Updated to upstream 1.2.8.

comment:70 Changed at 2010-07-19T23:04:24Z by 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.

comment:71 Changed at 2010-08-23T19:45:04Z by 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?

comment:72 Changed at 2010-08-31T23:33:24Z by 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?

comment:73 in reply to:  71 Changed at 2010-09-01T14:26:01Z by 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

comment:74 Changed at 2010-09-01T14:32:18Z by 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]]

comment:75 in reply to:  74 Changed at 2010-09-01T15:19:05Z by 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.

comment:76 Changed at 2010-09-01T15:32:31Z by 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.

comment:77 Changed at 2010-09-01T22:40:07Z by 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.

comment:78 Changed at 2010-09-06T00:24:57Z by 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.

comment:79 in reply to:  78 Changed at 2010-09-06T11:14:31Z by 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!

comment:80 in reply to:  77 ; Changed at 2010-09-14T20:43:13Z by 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.

comment:81 in reply to:  80 Changed at 2010-09-15T11:26:08Z by 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!

comment:82 Changed at 2010-09-19T20:32:08Z by 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 .

comment:83 Changed at 2010-09-30T06:03:04Z by 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.

comment:84 Changed at 2010-09-30T06:16:23Z by 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!

comment:85 in reply to:  84 Changed at 2010-10-01T15:00:02Z by 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!

comment:86 Changed at 2010-10-01T21:51:40Z by 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. ;)

comment:87 Changed at 2010-10-02T06:01:05Z by wilmer

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

comment:88 Changed at 2010-10-03T11:49:47Z by 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?

comment:89 Changed at 2010-10-04T22:13:22Z by 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.

comment:90 Changed at 2010-10-07T06:33:09Z by 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?

comment:91 Changed at 2010-10-07T09:26:59Z by 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?

comment:92 Changed at 2010-10-09T18:54:44Z by wilmer

Resolution: fixed
Status: newclosed

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.

Modify Ticket

Action
as closed The ticket will remain with no owner.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.