954310 - [meta] Add support for OTR and encrypted chats.

Status: RESOLVED FIXED

(Chat Core :: Security: OTR, enhancement)

Description

[Instantbot]

*** Original post on bio 877 by Ludovic Hirlimann <ludovic AT hirlimann.net> at 2011-06-30 09:49:00 UTC ***

Would be nice to be able to have conversations onver SSL and use OTR when possible.

Comment 1

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2011-06-30 10:37:22 UTC ***

Adding the OTR link and confirming

Comment 2

[Florian Quèze [:florian]]

*** Original post on bio 877 at 2011-11-16 23:26:01 UTC ***

I've just found this while looking for something else:
http://comments.gmane.org/gmane.comp.security.otr.devel/1161

http://gitorious.org/fireotr/fireotr/blobs/master/chrome/content/otr_wrapper.js may be reusable.

Comment 3

[Instantbot]

*** Original post on bio 877 by mozilla AT spacetrace.org at 2012-08-14 15:49:47 UTC ***

i think this is really important!

see https://bugzilla.mozilla.org/show_bug.cgi?id=779052

Comment 4

[Benedikt Pfeifer]

*** Original post on bio 877 at 2012-08-14 18:58:20 UTC ***

We have an extension that demonstrates how to modify the message content before sending them (for outgoing messages) or displaying them (for incoming messages) by the way:

http://hg.instantbird.org/addons/file/tip/rot13

Comment 6

[aleth [:aleth]]

*** Original post on bio 877 at 2012-09-04 21:38:09 UTC ***

libotr http://www.cypherpunks.ca/otr/software.php

Comment 7

[Instantbot]

*** Original post on bio 877 by jacob AT appelbaum.net at 2012-09-05 03:50:37 UTC ***

(In reply to comment #0)
> Would be nice to be able to have conversations onver SSL and use OTR when
> possible.

SSL/TLS is already supported, right?

OTR should be reasonably straight forward to add in terms of the actual crypto bits, though generation of keys requires a proper RNG - does instantbird have access to /dev/random properly?

Would it be best to link against libotr and create bindings? Or would it make sense to try to use one of the javascript implementations of OTR?

Comment 8

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2012-09-05 04:21:06 UTC ***

(In reply to comment #7)
> (In reply to comment #0)
> > Would be nice to be able to have conversations onver SSL and use OTR when
> > possible.
> 
> SSL/TLS is already supported, right?
Of course. SSL is the default for every protocol that supports it (well). (It's not actually the default on IRC because of bug 954724 (bio 1292).)

> OTR should be reasonably straight forward to add in terms of the actual crypto
> bits, though generation of keys requires a proper RNG - does instantbird have
> access to /dev/random properly?
Certainly not on Windows. ;) It looks like there's a variety of ways in Gecko [1][2][3] to get random numbers, what's considered a "proper RNG" to you?

> Would it be best to link against libotr and create bindings?
This could be done with js-ctypes, the link in comment 2 points to a (partial?) js-ctypes binding to libotr. I haven't looked at this code in a while though, so I'm unsure how good it is or if it's updated and supports all the features necessary.

> Or would it make
> sense to try to use one of the javascript implementations of OTR?
I only saw the one implementation on that site [4], I found it unacceptable:
- LGPL is undesirable, but OK.
- It uses CryptoJS, but we have access to native crypto routines via Gecko / NSS.
- It's really grossly formatted. :P It makes me tend to wonder if it can be done more cleanly.

This sounds a lot like when we were trying to find a blowfish JavaScript implementation for GSoC. wnayes ended up writing one from scratch because it was easier.

It's possible it would be a good starting point, but I'm not convinced. I tend to think it might make more sense to link to the libotr library, although I'm unsure how complicated that really would be.

[1] https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues
[2] https://developer.mozilla.org/en-US/docs/JavaScript_crypto
[3] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Math/random
[4] https://github.com/arlolra/otr

Comment 9

[Instantbot]

*** Original post on bio 877 by jacob AT appelbaum.net at 2012-09-05 04:38:06 UTC ***

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #0)
> > > Would be nice to be able to have conversations onver SSL and use OTR when
> > > possible.
> > 
> > SSL/TLS is already supported, right?
> Of course. SSL is the default for every protocol that supports it (well). (It's
> not actually the default on IRC because of bug 954724 (bio 1292).)

SSL or TLS proper? :)

> 
> > OTR should be reasonably straight forward to add in terms of the actual crypto
> > bits, though generation of keys requires a proper RNG - does instantbird have
> > access to /dev/random properly?
> Certainly not on Windows. ;) It looks like there's a variety of ways in Gecko
> [1][2][3] to get random numbers, what's considered a "proper RNG" to you?
> 

Well, in an ideal world, /dev/random on say, Gnu/Linux or the CryptoAPI RNG on Win32. If possible, it would be nice to have say, OpenSSL or libnss bindings for hardware acceleration if possible.

> > Would it be best to link against libotr and create bindings?
> This could be done with js-ctypes, the link in comment 2 points to a (partial?)
> js-ctypes binding to libotr. I haven't looked at this code in a while though,
> so I'm unsure how good it is or if it's updated and supports all the features
> necessary.
> 

I don't know if anyone has audited any of this stuff, so I suspect if we linked against libotr, we'd be in reasonable shape. libotr is certainly a lot though - we link against libgcrypt as well as other libraries.

> > Or would it make
> > sense to try to use one of the javascript implementations of OTR?
> I only saw the one implementation on that site [4], I found it unacceptable:
> - LGPL is undesirable, but OK.

arlolra made it LGPL, I think, to encourage more people to use it. I'll see him tomorrow, so I'll ask him about it.

> - It uses CryptoJS, but we have access to native crypto routines via Gecko /
> NSS.

It might make sense to extend arlolra's JS OTR for exactly this environment. It seems to me that it's the one case where a JS OTR implementation might be reasonable sometime soon.

> - It's really grossly formatted. :P It makes me tend to wonder if it can be
> done more cleanly.

Anything specifically?

> 
> This sounds a lot like when we were trying to find a blowfish JavaScript
> implementation for GSoC. wnayes ended up writing one from scratch because it
> was easier.

What did you need that for? :)

> 
> It's possible it would be a good starting point, but I'm not convinced. I tend
> to think it might make more sense to link to the libotr library, although I'm
> unsure how complicated that really would be.

Well, on Windows, we build libotr like so:
http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/libotr;a=blob;f=INSTALL;h=9a7a433d6db194f0091370963048491a934f7941;hb=HEAD#l34

We build pidgin-otr like so:
http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/pidgin-otr;a=blob_plain;f=Makefile.mingw;hb=HEAD

In a perfect world, I'd like to help get OTR into instantbird by default. If it was possible to add deps on libotr and then just bind with ctypes, I guess that would be pretty nice.

> 
> [1] https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues
> [2] https://developer.mozilla.org/en-US/docs/JavaScript_crypto
> [3]
> https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Math/random
> [4] https://github.com/arlolra/otr

Comment 10

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2012-09-05 10:45:28 UTC ***

(In reply to comment #9)
> Well, in an ideal world, /dev/random on say, Gnu/Linux or the CryptoAPI RNG on
> Win32. If possible, it would be nice to have say, OpenSSL or libnss bindings
> for hardware acceleration if possible.
So we should (fairly easily) be able to get to (most of) the guts of libnss, it's build into the Mozilla platform. And we really do prefer to do things in cross platform ways whenever possible.

> I don't know if anyone has audited any of this stuff, so I suspect if we linked
> against libotr, we'd be in reasonable shape. libotr is certainly a lot though -
> we link against libgcrypt as well as other libraries.
Hmmm...sounds heavy. :) If we used js-ctypes we could just take the pre-built binaries and use those, I think.

> > > Or would it make
> > > sense to try to use one of the javascript implementations of OTR?
> > I only saw the one implementation on that site [4], I found it unacceptable:
> > - LGPL is undesirable, but OK.
> arlolra made it LGPL, I think, to encourage more people to use it. I'll see him
> tomorrow, so I'll ask him about it.
Yes, well it's better than GPL! Since we include libpurple in Instantbird we could of course use this. But LGPL can't be used in Thunderbird (therefore not in the "chat core" of Instantbird).

> > - It uses CryptoJS, but we have access to native crypto routines via Gecko /
> > NSS.
> It might make sense to extend arlolra's JS OTR for exactly this environment. It
> seems to me that it's the one case where a JS OTR implementation might be
> reasonable sometime soon.
Possibly. I'd hope we could get rid of all dependencies on external JS libraries if we'd use it.

> > - It's really grossly formatted. :P It makes me tend to wonder if it can be
> > done more cleanly.
> Anything specifically?
I kind of get the feeling the person writing it isn't very familiar with JavaScript, it seems to use some confusing constructs. There's also few to no comments. :) I'd have to look at it again to know exactly what, however. I see there's a very brief test case, which is good -- does libotr have a test suite?

> > This sounds a lot like when we were trying to find a blowfish JavaScript
> > implementation for GSoC. wnayes ended up writing one from scratch because it
> > was easier.
> What did you need that for? :)
Bug 954928 (bio 1495), specifically the AIM importer, I believe.

> In a perfect world, I'd like to help get OTR into instantbird by default. If it
> was possible to add deps on libotr and then just bind with ctypes, I guess that
> would be pretty nice.
FWIW libotr is also GPL (I think), which means it can't be included in the chat core by default, but could be included in Instantbird.

Maybe you should come onto our IRC room and talk to us? It might facilitate conversation a bit: #instantbird on irc.mozilla.org Thanks for the information so far!

Comment 11

[Instantbot]

*** Original post on bio 877 by Karel Jára <jara.karel AT gmail.com> at 2013-07-15 07:55:24 UTC ***

Has this moved any further, or are there not enough developer resources to implement this?

Comment 12

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2013-07-15 12:14:33 UTC ***

(In reply to comment #11)
> Has this moved any further, or are there not enough developer resources to
> implement this?

If this had moved any further there would be updates here. As far as I know, none of the developers are really interested in working on this, but we would gladly help someone who is.

Comment 13

[Instantbot]

*** Original post on bio 877 by Gervase Markham <gerv AT gerv.net> at 2013-09-16 20:39:46 UTC ***

BTW, after a Mozilla policy change, LGPL is now fine for Thunderbird, as long as it's dynamically linked into a separate library. (Not sure what that would mean for a JS lib, but happy to explore it.) So that might make this bug easier to fix.

Gerv

Comment 14

[Instantbot]

*** Original post on bio 877 by arlolra <arlolra AT gmail.com> at 2013-10-02 18:47:31 UTC ***

For what it's worth, the OTR.js library switched to MPL v2.0 about 11 months ago and has had a modicum of auditing. It's being used in a few projects and hopefully isn't as gross as it was once purported to be :)

Comment 15

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2013-10-02 20:20:39 UTC ***

(In reply to comment #14)
> For what it's worth, the OTR.js library switched to MPL v2.0 about 11 months
> ago
I saw, that is great news for making it usable among a wide range of projects.

> and has had a modicum of auditing. It's being used in a few projects and
That's good and points in its favor.

> hopefully isn't as gross as it was once purported to be :)
This, unfortunately has not changed. I also dislike the number of external libraries used where we could use more "native" APIs.

https://bugzilla.mozilla.org/show_bug.cgi?id=779052 has a lot of good information from jcranmer about ways forward.

Comment 16

[Instantbot]

*** Original post on bio 877 by arlolra <arlolra AT gmail.com> at 2013-10-03 00:03:32 UTC ***

(In reply to comment #15)

> > hopefully isn't as gross as it was once purported to be :)
> This, unfortunately has not changed. I also dislike the number of external
> libraries used where we could use more "native" APIs.

In comment #10 you wrote,

> > > - It's really grossly formatted. :P It makes me tend to wonder if it can be
> > > done more cleanly.
> Anything specifically?
> I kind of get the feeling the person writing it isn't very familiar with
> JavaScript, it seems to use some confusing constructs. There's also few to no
> comments. :) I'd have to look at it again to know exactly what, however. I see
> there's a very brief test case, which is good -- does libotr have a test suite?

Which constructs are you referring to? I'm happy to make changes if it means you're more likely to use the library, or even if it just improves the codebase.

Also, I should mention, I'm willing to help with this effort, overall.

Comment 17

[Patrick Cloke [:clokep]]

*** Original post on bio 877 at 2013-10-05 14:45:45 UTC ***

(In reply to comment #16)
> Which constructs are you referring to? I'm happy to make changes if it means
> you're more likely to use the library, or even if it just improves the
> codebase.
Honestly, I greatly dislike the code. I find it extremely hard to read and most likely not very maintainable. My biggest issues with it are:
 - There are very few comments.
 - There are a lot of style issues with it, that aren't really "issues", but I don't exactly know what our policy for style in third-party code is.
    - Lots of usage of var instead of let and const.
    - The node.js style of anonymous functions makes a lot of the code pretty confusing to follow.
 - It uses a lot of node libraries that we have "native" access to:
    - CryptoJS (we have WebCrypto + NSS)
    - BigInt, we'd probably still need this or used typed arrays or something.

Pretty much...merging node.js style code into Mozilla via shims is EXTREMELY painful. I'd prefer not to do this.

> Also, I should mention, I'm willing to help with this effort, overall.
That's great! We've had a user being interested in #maildev on IRC about implementing this. You should try to coordinate efforts, most likely via IRC.

Comment 18

[Instantbot]

*** Original post on bio 877 by mozilla AT spacetrace.org at 2013-10-15 11:59:19 UTC ***

Just for info: There is a patch suggestion in thunderbirds bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=779052

Comment 19

[Instantbot]

*** Original post on bio 877 by tststts <titusstahl+bugzilla AT gmail.com> at 2013-11-30 12:02:45 UTC ***

Relevant bounty on bountysource: https://www.bountysource.com/issues/1012564-otr-encryption-in-thunderbird-chat

Comment 20

[arlolra]

A backend based on the API from https://bugzilla.mozilla.org/show_bug.cgi?id=983347 is available at https://github.com/arlolra/ctypes-otr, with a minimal amount of UI.

We need to discuss,

 * UI requirements and implementation

 * Path to upstream the code

Comment 22

[Ruben]

Bounty on Bountysource: https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

Comment 23

[arlolra]

Attachment: libotr.patch

Attaching the libotr wrapper for review. We can hopefully go through these modules independently.

Comment 24

[Patrick Cloke [:clokep]]

Comment on attachment 8547924 [details] [diff] [review]
libotr.patch

Review of attachment 8547924 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry if some of my questions are naive, I don't fully understand ctypes. :) Overall I think this is a good start, but I dislike the design...that might just be because of ctypes. Can you point me to where this code is used though? I need to see some use cases to offer more feedback.

::: chat/modules/libotr.jsm
@@ +2,5 @@
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +/*
> + * js-ctypes wrapper for libotr

I'm not sure if this comment needs to be expanded or not, but libOTR and libC are...what exactly? The libOTR/libC API done in ctypes? Do they wrap it to any greater degree than that?

@@ +9,5 @@
> +const EXPORTED_SYMBOLS = ["libOTR", "libC"];
> +
> +const {interfaces: Ci, utils: Cu, classes: Cc} = Components;
> +
> +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry);

We only use this once, I think. So maybe put it near that.

@@ +14,5 @@
> +
> +Cu.import("resource://gre/modules/ctypes.jsm");
> +Cu.import("resource://gre/modules/Services.jsm");
> +
> +let abi, libcPath;

Add a comment above this saying what we're trying to do in this block. Also, please indent your case statements.

@@ +26,5 @@
> +  libcPath = ctypes.libraryName("c");
> +  break;
> +case "Linux":
> +  abi = ctypes.default_abi;
> +  libcPath = "libc.so.6";

Why is this not ctypes.libraryName("c") (i.e. the same as Darwin).

@@ +29,5 @@
> +  abi = ctypes.default_abi;
> +  libcPath = "libc.so.6";
> +  break;
> +default:
> +  throw new Error("Unknown OS");

Did you test this situation? What happens? Does the export even work?

@@ +32,5 @@
> +default:
> +  throw new Error("Unknown OS");
> +}
> +
> +let libotr;

Please add an explanatory comment saying what this is doing.

@@ +37,5 @@
> +try {
> +  // try in chrome
> +  let uri = "chrome://otr/content/" + ctypes.libraryName("otr");
> +  uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null));
> +  libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path);

Will OS.File simplify any of this path manipulations?

@@ +40,5 @@
> +  uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null));
> +  libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path);
> +} catch(e) {
> +  // look in standard locations
> +  libotr = ctypes.open(ctypes.libraryName("otr"));

What if it isn't found here either?

@@ +44,5 @@
> +  libotr = ctypes.open(ctypes.libraryName("otr"));
> +}
> +
> +// libotr API version
> +const otrl_version = [4, 1, 0];

Does this represents the version we support? I have a feeling this should be named with our normal kConstantCamelcase constant formatting...

@@ +741,5 @@
> +
> +let libc = ctypes.open(libcPath);
> +
> +let libC = {
> +  close: () => libc.close(),

I find it strange you have a close() function here, but that the open() seems to take place up above in the module. It might make sense to add an init function here which does the logic of finding where libc is, etc. and setting it as a property on this object. Who calls libc.close() anyway? What if there are multiple consumers? (Or maybe this can be done because of the libc.declares below?)

Comment 25

[arlolra]

Comment on attachment 8547924 [details] [diff] [review]
libotr.patch

Review of attachment 8547924 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the feedback. This library is loaded here: https://github.com/arlolra/ctypes-otr/blob/master/chrome/content/otr.js#L8

::: chat/modules/libotr.jsm
@@ +2,5 @@
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +/*
> + * js-ctypes wrapper for libotr

Just the parts of the libOTR / libC API necessary for the extension, done in ctypes. Nothing more than that in this file.

@@ +9,5 @@
> +const EXPORTED_SYMBOLS = ["libOTR", "libC"];
> +
> +const {interfaces: Ci, utils: Cu, classes: Cc} = Components;
> +
> +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry);

Done

@@ +14,5 @@
> +
> +Cu.import("resource://gre/modules/ctypes.jsm");
> +Cu.import("resource://gre/modules/Services.jsm");
> +
> +let abi, libcPath;

Done

@@ +26,5 @@
> +  libcPath = ctypes.libraryName("c");
> +  break;
> +case "Linux":
> +  abi = ctypes.default_abi;
> +  libcPath = "libc.so.6";

I think `libraryName()` is pretty naive in that it just prepends "lib" and appends the platform specific extension (".so", ".dll"). And, because of multiarch support in Linux, libc.so isn't found in the standard library search paths.

@@ +29,5 @@
> +  abi = ctypes.default_abi;
> +  libcPath = "libc.so.6";
> +  break;
> +default:
> +  throw new Error("Unknown OS");

It throws an exception and the extension isn't loaded.

1423597990958	addons.xpi	WARN	Exception running bootstrap method startup on ctypes-otr@tormessenger: Error: Unknown OS (chrome://otr/content/libotr.js:24) JS Stack trace: @libotr.js:24:1 < @otr.js:8:1 < [e-mail]:308:3 < [e-mail]:4440:9 < [e-mail]:2162:13 < [e-mail]:208:12 < [e-mail]:669:5 < [e-mail]:837:9 < [e-mail]:2468:5 < [e-mail]:55:7

@@ +32,5 @@
> +default:
> +  throw new Error("Unknown OS");
> +}
> +
> +let libotr;

Done

@@ +37,5 @@
> +try {
> +  // try in chrome
> +  let uri = "chrome://otr/content/" + ctypes.libraryName("otr");
> +  uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null));
> +  libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path);

I don't think so ... but these steps are to determine the location of the extension directory. We'll need to change this to wherever you plan on bundling libotr, which for the other shared object files, seems to be the application directory. In which case, ctypes.open(ctypes.libraryName("otr")) should be sufficient.

@@ +40,5 @@
> +  uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null));
> +  libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path);
> +} catch(e) {
> +  // look in standard locations
> +  libotr = ctypes.open(ctypes.libraryName("otr"));

It'll throw if it can't find the library.

@@ +44,5 @@
> +  libotr = ctypes.open(ctypes.libraryName("otr"));
> +}
> +
> +// libotr API version
> +const otrl_version = [4, 1, 0];

This is the libotr api version we are using, not the protocol versions we support. It needs to be set so that the right callbacks and whatnot are fired in libotr.

@@ +741,5 @@
> +
> +let libc = ctypes.open(libcPath);
> +
> +let libC = {
> +  close: () => libc.close(),

Right, so you hinted at it in the "maybe this can't be done because of the libc.declares below". The library needs to be open before you can declare an api from it. But I agree that it's a little strange and am open to less cumbersome organization.

Close is called at the extension unload time, which is kind of redundant in that it'll be closed automatically when the libc var is gc'd. Multiple consumers would be a problem but not a scenario that seemed to need support.

Comment 26

[tstststst]

The bounty for this bug is now at $1K at https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

Comment 27

[Patrick Cloke [:clokep]]

Please keep this bug to technical discussion. Thanks.

Comment 28

[Florian Quèze [:florian]]

Comment on attachment 8547924 [details] [diff] [review]
libotr.patch

Review of attachment 8547924 [details] [diff] [review]:
-----------------------------------------------------------------

I didn't expect to review this before it had been updated to address Patrick's comments, but I had a quick look and noticed some things to comment on.

::: chat/modules/libotr.jsm
@@ +9,5 @@
> +const EXPORTED_SYMBOLS = ["libOTR", "libC"];
> +
> +const {interfaces: Ci, utils: Cu, classes: Cc} = Components;
> +
> +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry);

"Cr" is always used for Components.results, so please use a different variable name.

@@ +35,5 @@
> +
> +let libotr;
> +try {
> +  // try in chrome
> +  let uri = "chrome://otr/content/" + ctypes.libraryName("otr");

I don't think looking for a binary library in chrome:// is a good idea. Chrome files are usually stored in compressed jar files.

If you want to preserve a way to make this work in an add-on, I think you would want to use a resource:// URI instead.

@@ +51,5 @@
> +
> +const time_t = ctypes.long;
> +const gcry_error_t = ctypes.unsigned_int;
> +const gcry_cipher_hd_t = ctypes.StructType("gcry_cipher_handle").ptr;
> +const gcry_md_hd_t = ctypes.StructType("gcry_md_handle").ptr

This part of the file looks like it has been somehow automatically generated, but given the missing ';' here, I guess it hasn't. I don't know how to usefully review this part of the file, as I don't know the libotr API, and am not really familiar with ctypes.

Comment 29

[u465525]

Hello, everybody

I just saw two news this week about "Tor Messenger Beta" (https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily) that seems to be "based on Instantbird" with "OTR (Off-The-Record) Messaging in XMPP-based services are default enabled. " (https://tlhp.cf/tor-messenger-review/).

How does this relates to this issue?

Kind regards,
Daniel

Comment 30

[aleth [:aleth]]

(In reply to daniel neis from comment #29)
> Hello, everybody
> 
> I just saw two news this week about "Tor Messenger Beta"
> (https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily)
> that seems to be "based on Instantbird" with "OTR (Off-The-Record) Messaging
> in XMPP-based services are default enabled. "
> (https://tlhp.cf/tor-messenger-review/).
> 
> How does this relates to this issue?
> 
> Kind regards,
> Daniel

Arlolra's OTR addon (that is shipped as part of Tor Messenger) can be found here https://github.com/arlolra/ctypes-otr. It works with Instantbird nightlies too (but not with IB 1.5).

Comment 31

[github]

There is still a bounty of 1020$ on this issue, and it seems like the bounty will be cut low during the next few months, since bountysource charges a fee each month if a project is inactive. So if someone has the time, now is the time to claim the bounty: https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

Comment 32

[Kai Engert (:KaiE:)]

(In reply to github from comment #31)
> There is still a bounty of 1020$ on this issue, and it seems like the bounty
> will be cut low during the next few months, since bountysource charges a fee
> each month if a project is inactive. So if someone has the time, now is the
> time to claim the bounty:
> https://www.bountysource.com/issues/5925617-add-support-for-otr-and-
> encrypted-chats

Maybe this money should simply be donated to the TB project, once it's implemented.

Comment 33

[Kai Engert (:KaiE:)]

We're exploring the approach to port https://github.com/arlolra/ctypes-otr
to Thunderbird, which would require to bundle libotr and its gnupg-project dependency libs.
Bug 1518091 is about clarifying if bundling those libs is possible.

Comment 34

[Kai Engert (:KaiE:)]

This feature will require several individual steps. I suggest to use this bug as the overall tracking bug, and use separate bugs for the individual tasks.

Comment 35

[gustavorps]

Bountysource update their Terms of service:

2.13 Bounty Time-Out.
If no Solution is accepted within two years after a Bounty is posted, then the Bounty will be withdrawn and the amount posted for the Bounty will be retained by Bountysource. For Bounties posted before June 30, 2018, the Backer may redeploy their Bounty to a new Issue by contacting [e-mail] before July 1, 2020. If the Backer does not redeploy their Bounty by the deadline, the Bounty will be withdrawn and the amount posted for the Bounty will be retained by Bountysource.

Comment 36

[Patrick Cloke [:clokep]]

Kai -- can we close this as "done"? I know there's plenty of follow-ups that could improve OTR, but it seems that overall it is implemented.

Comment 37

[Kai Engert (:KaiE:)]

If you want this closed, it's fine with me. On the other hand, it's also a meta bug, a tracker. Does it make sense to close meta bugs that still have items that are tracked?

Comment 38

[Patrick Cloke [:clokep]]

(In reply to Kai Engert (:KaiE:) from comment #37)

Does it make sense to close meta bugs that still have items that are tracked?

It seems to me that the OTR specific follow-ups are in the right component so we can consider this "Initial support for OTR", which is done.