OTR and general security stuff
jacob at appelbaum.net
Tue Feb 12 18:51:38 EST 2013
> 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:
>> 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:
>> 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
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
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
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.
> 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,
More information about the Devel