OTR and general security stuff

[Jacob Appelbaum]

Ethan Blanton:
> Jacob Appelbaum spake unto us the following wisdom:
>> I'm writing to this list as datallah suggested that I write to
>> this address. I hope it is useful/welcome.
>> 
>> I've been a Pidgin/libpurple user for a long time. Lately, I've
>> been working with datallah to find security related issues. A few
>> of the issues I've worked or reported are here:
>> 
>> https://developer.pidgin.im/search?q=ioerror 
>> http://hg.pidgin.im/pidgin/main/rev/66dc0da8257b
>> 
>> I've also recently reported another remotely exploitable issue
>> privately to datallah. He is fun to work with and I look forward to
>> working with him more to audit.
> 
> And we look forward to more reports!  We've been receiving a 
> gratifying amount of external assistance with correctness and
> security auditing lately.  Thanks for your help on that front.
> 

You're welcome. I think that it would be nice to do a formal
audit/review or a bug hunt party. If everyone audited sections of code
for various kinds of bugs, I bet we could shake out a lot of progress on
that front. I've largely focused on the HTTP and image parsing code but
I'm sure there are other areas that are in need of focus.

>> I'm part of the OTR development team and I really want to help make
>> OTR easier to use. I've worked on a few improvements to various IM
>> clients (such xmpp-client, the golang xmpp/OTR client, Gajim,
>> Adium, etc) regarding security and OTR. I've recently opened a bug
>> where I'd like to discuss the idea of shipping our pidgin-otr
>> module in the Windows release of Pidgin proper:
>> 
>> https://developer.pidgin.im/ticket/15513
>> 
>> I understand that this could be potentially contentious and I even 
>> understand some of the reasons. As a result, I wanted to open a 
>> discussion where we discuss the issues involved and hopefully move 
>> towards a more secure IM transport option that works across around
>> a dozen IM clients.
> 
> So, here's a few hits on how I feel about it, as a Pidgin developer:
> 
> * I get the sense that a sizeable minority of our users use OTR. 
> Most, but not all, of them seem to be power users (as expected), and
> we don't hear much from them.
> 

I think that this is probably accurate. I know that lots of non-power
users also use Pidgin with OTR; it is mostly journalists and activists
in my experience.

> * While I don't use it personally (I simply use email, rather than 
> IM, for sensitive information), I like the *idea* of plugins like 
> OTR.
> 

Glad to hear it. :)

I admit, I hope that it can come to pass as a thing that Just Works for
you. That is actually a target use case for OTR - casual protection that
is also *strong* in the face of an attacker.

> * We've had very little contact from anyone involved with OTR.  In 
> fact, this may be the first I've heard of (certainly we've heard from
> you before, Jacob, but I don't think I knew you were an OTR 
> developer).  This makes me somewhat nervous about "blessing" the OTR
> plugin; in particular, there have been a few long-standing and 
> unaddressed bugs (not that I can think of what they are at the 
> moment, but I'm sure someone can) that have plagued Pidgin users for
> years, and we've had no avenue of contact and seen no support on that
> front.
> 

I'm not sure of any long standing bugs - we believe the latest version
is pretty solid. If there is anything outstanding, please tell me about
it and I'll look into addressing it?

> * The above notwithstanding, OTR is a reasonably solid plugin.
> 

Thanks - Ian has done a great job over the years. I'm a new addition to
the OTR development team, so my hope is to help keep it that way!

> * We don't take plugins unless we believe they are going to be 
> maintained, and their maintainer is going to work with us in a 
> positive fashion, because we've been burned by drive-by plugins 
> before.
> 

We have a solid commitment to maintain the plugin moving forward. My
personal commitment to the plugin is actually what motivated me to
really start auditing libpurple/pidgin.

> * You are not an unknown quantity to us, and if you're willing to 
> *commit to supporting this plugin going forward*, we can probably 
> arrive at an acceptable solution to the previous three points.

I know that Ian and I both plan to keep working on pidgin-otr in the
long term. This is an important project for both of us and we don't take
this responsibility lightly.

The main thing that I would personally commit to doing is ensuring that
our development is in sync with any in-tree code base. We currently use
git - though I see no reason that we couldn't merge every upstream
commit into the main pidgin/libpurple hg tree.

I am more than happy to find a way to make that happen in near-real time.

> 
> * I am not interested in including a third-party binary plugin in
> our Windows build only; I would be more inclined to bring the Pidgin 
> OTR plugin (or a version thereof) into the Pidgin sources, and 
> release it on all platforms where the dependencies are met.  (I see 
> that you propose this on your bug.)
> 

I tend to think that this is a fine idea. I would say that the intention
here is not to fork but rather to ensure that pidgin-otr development is
kept in sync with pidgin itself. This is a reasonable request and it
seems rather straight forward.

> So ... the net wrapup of all of that is that I'm left feeling a
> little bit nervous about how smoothly this will go for Pidgin in the
> long run, but I think it's a positive general step if you are willing
> to step up for long-term maintenance, and I support it.
> 

I'm in.

> This also leaves a possible discussion for integrating OTR as a 
> non-plugin Pidgin feature, as well as OTR for finch.  :-)

In an ideal world, I'd like to see OTR enabled by default and as a part
of Pidgin as it is in Adium. That would be an amazing step forward and
it would certainly motivate finch development, I think.

All the best,
Jacob