[tor-talk] pidgin and tor

[sh-expires-12-2015 at quantentunnel.de]

On Mon, Oct 05, 2015 at 04:00:36PM -0700, coderman wrote:
> the primary problem with Pidgin is libpurple [
> https://pidgin.im/news/security/ ] and a more appropriate mitigation
> would be Qubes isolation, perhaps Whonix-Qubes on new 3.0. :)

One of the major problems is the design of Pidign, which tries
to build a convenient IM client before it takes security into
consideration - or that is my observation since its inception:

ldd /usr/bin/pidgin | wc -l result 78
ldd /usr/bin/irssi | wc -l result 16

Many supported protocols lack this consideration too, all
Pidgin does is to inherit a lot of broken stuff, and I mean A LOT.

Still, it is possible to a achieve a high degree of privacy.
The amount of "security" will vary and depend on many factors.

A vm is none of them:
Confining it, doesn't make it more secure, and it mitigates nothing in 
pidgin or libpurple. A broken IM client is still broken, even when 
confined (I am tempted to say buried) in a VM.

If OP has to rely on an IM, like pidgin or a protocol, there is no more 
or added "security" by putting it into a vm or container.
All he gains is isolation in a best case scenario. A vm doesn't
add privacy, anonymity, security or authenticity, it is the contrary;
it adds complexity, which we should avoid.

Honestly, let's recommend a more secure implemenation 
of the protocol OP wishes to use and educate OP how to use it in
a manner, that neither privacy and anonymity of the involved parties
are compromised and the authenticity of the exchanged messages is given.

Using Tor with Pidgin, we are at a disadvantage:
All supported protocols, require a 3rd party to operate, most
of them are proprietary iirc. If you want to use one of them with Tor, 
you are clearly at a disadvantage since you have to rely on another party
to manage your communications. 

A accetable workaround could be to establish communication 
(since we already use Tor) using a hidden service.

I know of one approach, to write a plugin that uses hiddenservices.

> as indicated in the thread, there are not any good alternatives.
> xmpp-client and irssi-xmpp-otr, others quite weird usability wise.
>    [old schoolers may disagree *grin*]

You can add an arbitrary amount of protocols (and vms, UX and whatnot) 
to pidgin and chances are pretty high, you become more and more vulnerable.
Best case is a lot of overhead and nothing else.

Anyway, aren't the new school's approaches or paradigms like XML or SOAP some 
of the major sources of problems in Pidgin, along with smiley-themes and
buddy-icons? That is the impression I get.

If security is a result of good design, good design is when there
is nothing left to remove and the design is still secure.

Contrary to the popular misconception, that security is some kind of
fairydust, product or duct-tape that we can apply to protocols or software
afterwarts.