Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Using Gajim Instead of Pidgin for More Secure OTR Chat

Jacob Appelbaum jacob at
Wed Feb 20 23:20:48 PST 2013

Micah Lee:
> I just wrote a blog post that people here might find interesting about
> using Gajim, a chat client written in python, and Gajim's OTR plugin, a
> purely python implementation of the OTR standard, instead of Pidgin and
> libotr.
> Also, I wrote a script called pidgin2gajim that takes the OTR keys from
> Pidgin and reformats them to work in Gajim, so you can keep your old
> Pidgin key.

A few people, myself included, had an audit (drinking) game with gajim a
while back - they were quite responsive. There were a number of rather
insecure design issues that I would strongly caution rechecking - one of
them was that the Python OTR module was not included in the default
Gajim release. If I remember correctly, one had to download it and
install it from within a plugin wizard of sorts over http:

I think they fixed that by adding HTTPS - in python - which well, hrm.
Looks like a fun thing to follow up on, eh?

I think their HTTPS code is here:

They wrote some DH code here:

Other bugs for OTR are interesting to read:

Here are a few other bugs I reported including remote code execution issues:

A friend's bug reports:

A few days ago, I also managed to remotely crash a friend using the most
recent Gajim in an OTR session. His Gajim client sent me this in response:

<message to="me" type="chat" id="30" from="myfriend/Gajim">
<body>18:37:16 (E) gajim.c.ged Error while running an even handler:
<bound method OtrPlugin.handle_incoming_msg o
f <gotr.otrmodule.OtrPlugin object at 0x1845750>>Traceback
(most recent call last):  File "/usr/share/gajim/src/common/",
line 91, in raise_event    if handler(
*args, **kwargs):  File
"/home/user/.local/share/gajim/plugins/gotr/", line 521, in
handle_incoming_msg    appdata={'session':event.session})  File
cal/share/gajim/plugins/gotr/potr/", line 219, in
receiveMessage    plaintext, tlvs =
self.crypto.handleDataMessage(message)  File
"/home/user/.local/share/gajim/plugins/gotr/potr/", line 195, in
handleDataMessage    tlvs = proto.TLV.parse(tlvData)  File
"/home/user/.local/share/gajim/plugins/gotr/potr/", line 318, in
parse    return [tlvClasses[typ].parsePayload(data[:length])] \KeyError:
0 </body><thread>xxxx</thread><nos:x value="enabled"
xmlns:nos="google:nosave"/><arc:record otr="true"

I didn't report it and I'm not sure if my friend did either. I'd guess not.

I think this was the message that I sent to my friend that caused the
above stack trace to be sent over jabber to me:
<message to='myfriend' from='me'
xmlns:nos='google:nosave' value='enabled'/><arc:record
xmlns:arc='' otr='require'/></message>

Anyway, Gajim isn't free of issues and the OTR plugin is written in
Python. That may be good news but I admit, I haven't seen if there are
any test vectors that compare all of the functionality. At one point the
potr library author had considered unit testing their inputs/outputs
against the expected libotr inputs/outputs. I'm not sure if that happened.

They are at least Tor (support) friendly which is nice of them:

All the best,

More information about the liberationtech mailing list