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. -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
