Pidgin no longer exposes plaintext messages / pidgin state through DBus
Originally created by @maqp on #14733 (Redmine)
Regarding #14612 (closed)
Quoting “ultramancool” in the upstream ticket:
>It’s ridiculous to try to fix an issue where the user must be completely compromised in order to have, because then everything is an issue. How hard would it really be for an attacker to simply kill your pidgin process and restart it with a custom LD_PRELOAD? Not to mention gtkparasite or similar could easily be used to grab the messages from the pidgin window, as could common screenshoting tools. When an attacker can execute code, all bets are off, you simply cannot fix this sort of issue no matter how you pursue it. The only way to protect against this would be complete and total desktop and process isolation, which are things we simply do not have right now. This is not “security” this is simple obscurity. Obscuring the problem does not solve it.
I’ve been working on a high assurance solution for endpoint secure
messaging since 2012 and for that, DBus IO for OTR plaintext messages is
a feature, not a bug; TFC (https://github.com/maqp/tfc) is a HW/SW
messaging system that encrypts/decrypts messages on external computers,
that is, physically separated from networked computer running Tails. The
ciphertexts are exchanged between computers using hardware data diode
enforced, unidirectional serial interfaces and a protocol converter
program that talks to Pidgin using DBus. This approach entirely solves
the issue of key/pt exfiltration from compromised Tails (Read the GitHub
readme for more details). You can observe the interaction of the three
computers here:
The fix for #14612 (closed) has completely broken IO between application in Terminal (NH) and Pidgin. Please either re-enable DBus for Pidgin, or help me add necessary commands to installer that re-enable DBus for TFC users.