MEDIA // Libpurple based IMs

[Joseph Cox]

Hey, thanks for the information.

Sure: the main issues I've come across with libpurple, and then Pidgin
on top of this, in my research are that:

- libpurple is a very large library, meaning that bugs are often
discovered within it, particularly memory corruption bugs.
- Pidgin does not enable end-to-end encrypted messages by default, but
these are handled by the OTR plugin, which is not baked into the design.
- and that some members of the infosec community seem to think that
Pidgin developers take a lot of time to patch vulnerabilities (see this
tweet from Appelbaum: https://twitter.com/ioerror/status/525622470666358784)

Various people from the same infosec community have been switching to
Adam Langley's command line xmpp-client, and some have been using CoyIM,
based on top of this, both written in Go. Any thoughts you might have on
those clients would be appreciated too.

Thanks a lot,

Joseph

On 04.02.2016 19:54, Ethan Blanton wrote:
> Joseph Cox spake unto us the following wisdom:
>> Hey, I'm Joseph Cox, a journalist from VICE's Motherboard.
>>
>> I'm writing about the issues with libpurple, and the potential move by
>> some people to other chat clients (such as CoyIM).
>>
>> Can I ask for Pidgin's comment on the security of its client?
> Probably, but we're going to need more information to go on.  What
> "issues with libpurple", and what "some people"?
>
> Broadly speaking, we take security seriously and have a reasonable
> track record on both number of flaws and addressing those flaws,
> particularly given that the libpurple software base is almost two
> decades old (and thus suffered from several years of development
> before the open source community was particularly clued into many
> security concerns).
>
> You may find this interesting:
>
>     https://www.eff.org/secure-messaging-scorecard
>
> Note that Pidgin w/ OTR ticks every checkbox in their survey,
> including independent third-party code reviews.  We have been
> fortunate to have had the support of several independent teams over
> the years, reviewing our code for security and reliability flaws.
>
> If you can give us more to work with, we might be able to provide you
> with better information.
>
> Ethan