MEDIA // Libpurple based IMs

[Joseph Cox]

Great, thank you for the detailed answers, appreciated. I'll send you a
link once it goes up.

Cheers,

On 04.02.2016 21:18, Ethan Blanton wrote:
> Joseph Cox spake unto us the following wisdom:
>> 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:
> OK.  These are unsurprising, and relatively common
> misinformation/misconceptions, but like most such common errors, they
> contain a grain of truth.
>
>> - libpurple is a very large library, meaning that bugs are often
>> discovered within it, particularly memory corruption bugs.
> This is true, libpurple is very large.  This is always a disadvantage.
> However, it does not necessarily mean that it is particularly *bad*
> for its size.  While one can expect a more or less constant lower
> bound on the number of bugs per line of code (Cf. Frederick Brooks and
> reams of later study), thus suggesting that larger code means more
> bugs, it's also that case that libpurple is effectively partitioned in
> such a way that no given account touches large parts of that code; for
> example, a bug in the Yahoo! protocol will not adversely affect an
> XMPP account.  On the other hand, the multi-protocol nature of
> libpurple means that that XMPP account probably descends through a
> deeper software stack than a single-protocol client would use.
>
> I don't think that libpurple is going to be particularly larger than
> another *multiprotocol* IM library, nor contain particularly more
> bugs.  Individual protocol plugins may.  In particular, some protocol
> plugins have been provided to us by third parties and may even require
> accounts on IM networks that we do not or cannot use (such as
> corporate messenger servers).
>
>> - 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.
> This is true, but it is true of all OTR clients, to my knowledge. Some
> ship the OTR plugin with the client itself, but OTR does not provide a
> client.  Note that our intention is to ship the OTR plugin with Pidgin
> 3 when it is released.  Note also that this will not make it "baked
> in", it will simply be a first-party-supported plugin.  Some libpurple
> clients (such as Adium for OS X) already provide first-party support
> for OTR.
>
> There is a real lack in the market of an end-to-end secure instant
> messaging protocol with widespread adoption and sound security
> practices.  There are some relatively recent entries (such as Whisper
> Systems' TextSecure, which unfortunately relies on their commercial
> servers unlike, say, XMPP; Tox; etc.), but they generally either have
> significant flaws or are not yet well-adopted.  (In some cases a
> protocol plugin could be provided for libpurple, and in some cases
> there are already third-party protocol plugins.)
>
> Thus OTR.  OTR runs on top of existing, established IM networks and
> provides a fair measure of end-to-end security.
>
>> - 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)
> That tweet is subtle and may not mean what you think it means.  The
> bug in question was actually simply an instance of a general error
> first published by Moxie Marlinspike two years before the reporting
> and correction of the related bug in Pidgin.  Jacob's point was more
> despair that Moxie's bug was still relevant, I think.  In any case,
> the underlying problem was a lack of functionality in the open source
> SSL/TLS libraries NSS and GnuTLS (certificate basic constraints
> validation), for which we had a workaround.  Certainly it would have
> been good for us to have fixed the bug earlier, but it's not like we
> had a specific security-related bug report that we sat on for years.
>
>> 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.
> I have used neither project, and cannot comment.  Other Pidgin
> developers may have some comment.
>
> We have a lot of thoughts about security within the libpurple team,
> and we have differing positions on the various reoccurring accusations
> that libpurple is insecure.  Broadly speaking, I think we feel that
> most such accusations are either a) in denial of the state of security
> of Internet-connected software in general and of our application of
> rasonable practices to the problem, b) tied to specific errors that
> the accuser sees as more important than we believe the merits of
> libpurple are in a larger context, or c) general concerns that large
> software has lots of bugs (hello, web browsers!).  Certainly we have
> had bugs, and bad bugs, in the past, and certainly there are design
> decisions in libpurple that would be best reconsidered if we were
> starting a library today but were either necessary or even best
> practice in the 90s (such as implementing network protocols in C).
>
> Note that we maintain a list of known security flaws in released
> versions of libpurple, that we issue CVEs proactively for flaws we
> find ourselves, and that we coordinate flaws (discovered in-house or
> reported by external developers) with packagers and distributions to
> make timely disclosures with available fixes for remotely-triggerable
> flaws.  (See https://pidgin.im/security/ and
> https://pidgin.im/news/security/ .) Note also that the last major
> reported flaws were in late 2014, meaning libpurple went through all
> of 2015 without any first- or third-party reported flaws requiring
> disclosure.  That does NOT mean that there will not be remote exploit
> flaws reported tomorrow, or that there aren't lurking bugs with severe
> consequences (Cf. OpenSSL!), but I think it does indicate that we take
> security seriously and have a mature code base.
>
> Of course, if any given user finds that another client better responds
> to their threat analysis or has a better, more secure implementation,
> then we absolutely encourage that user to adopt the software that they
> trust best.  We would also love to know why that decision was made and
> how we might improve libpurple to meet their threat model head-on, but
> such things still take time and may not be possible at all.  (E.g., we
> are unlikely to make libpurple a uniprotocol library simply to reduce
> the attack surface!)
>
> Hopefully there's something helpful to you there.  Good luck with your
> article.  Other developers may chime in later.
>
> Ethan