[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Adding new software to Whonix

Sure. We nailed it anyways already (yesterday on IRC). Both pidgin (with evil protocols disabled, see Tails) and KeePassX will be shipped by dist-upgrade to Whonix 8 soon. That is, if I understood Patrick correctly.[/quote]

Is this correct?

Default OTR, no logs, with Pidgin?

“soon”: How soon is soon, this is the question. But now that there are motivated testers, stabilization of new features can indeed go much faster.

About pidgin there are open questions.

Tails randomizes IRC nickname at boot time. The script can be found here:
https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/lib/live/config/2010-pidgin

The critical part is…

sudo -H -u "${LIVE_USERNAME}" sed -i'' "s,XXX_NICK_XXX,${NICK}," "/home/${LIVE_USERNAME}/.purple/${file}"

This basically searches for XXX_NICK_XXX in their default pidgin config and replaces that string with a random nick. On new boot of Tails, XXX_NICK_XXX gets restored. This wouldn’t be the case in Whonix, since it’s persistent. Which means, this script wouldn’t work in Whonix without tweaks. Because Whonix would store.

Do we want random IRC nicks in Whonix? Or do we just omit this script and let the user choose it’s nick? Or ship with pidgin IRC disabled by default? I tend to the latter.

Tails Design, Pidgin:
https://tails.boum.org/contribute/design/#index42h3

In my opinion it is a good idea to learn from Tails. Eventually they closed any holes we don’t want to re-invert in Whonix.

When answering to CTCP requests, Pidgin does not leak any information apart from PING and VERSION (Purple IRC), which is deemed acceptable as there are probably other weirdness in how the protocol is implemented, that disclose as much.
So it means it does leak PING and VERSION. From fingerprinting perspective this is non-ideal.

Whonix already has an IRC client, namely XChat, that doesn’t leak anything.

I think it would be best to ship Pidgin with IRC disabled by default.

For those fit with git, I started a pidgin branch:

For your convenience, changes at time of writing include:

(The tails implementation https://git-tails.immerda.ch/tails/plain/config/chroot_local-hooks/09-remove_unsupported_pidgin_libs cannot be used, because when pidgin gets updated, these files would be recreated. Therefore they have to be moved out of the way using config-package-dev.)

And what do we want to take from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/skel/.purple ? If we disable IRC, by default, we can omit accounts.xml, blist.xml and certificates (would be a burden keeping it updated anyway).

What about prefs.xml?

Can we use Tails’ prefs.xml as is?

What changes? Set to OTR-only by default?

How to add credit (license text) to their xml?

About Pidgin.

We are allowing only two protocols, XMPP and IRC, correct?

Pidgin sucks as an IRC client (it’s clumsy for anyone who used a real IRC client) and we already have XChat so we only need to worry about XMPP support. Random nicks are not needed.

I don’t like Pidgin. The goal of the software seems to be more “1 billion users” then “secure use”.

Alternatives:

xmpp-client;


+: OTR, light, from the creator of Pond and ioerror works(ed) on it. I know, namedropping is not much of an argument
-: It is not available in debian repositories.

MCabber (console);
http://mcabber.com/
+: OTR, light, in debian repo

Profanity;
http://www.profanity.im/otr.html
+: OTR, light, looks great
-: It is not available in debian repositories.

I tend to not enable IRC as outlined above. Only XMPP.

I don’t like Pidgin as IRC client either, but that’s not the point.

Console clients are too unpopular. Pidign is a good choice, it had quite some scrutiny with respect to Tor. Also good for joining same anonymity set as Tails.

Stuff not in Debian is bad, due to maintenance overhead (keeping up with updates as they update).

Default Application Policy (not written in stone):

I agree with having pre-installed software that users expect.

But… There are so many ways users can shoot themselves in the foot. I don’t agree with staying quiet and letting the user figure it out the hard way, but I think sometimes we need to say “there is no safe way to do this yet”.

There is a reason the tor project rejected pidgin as the base of their new Tor Instant Messager Bundle… that thing uses C code to parse strings in order to patch over old problems.

Users can log into their facebook via the tor browser. OK, we can’t stop that. Nor is that reason to say that the tor browser isn’t safe. Some degree of user education is necessary, of course.

But at some point, it’s just too easy to fall into temptation and log into your “non anonymous” IM account. Or accidentally hit a button that disables OTR; or not know to look for a small piece of text that says “OTR still negotiating, anything you say now won’t be encrypted”; or whatever.

I don’t know where I’m going with this, but I think I’m touching on the issues we have to confront when we tell people “This is how you can be anonymous online with Whonix”. People are going to think “Ah, I just install my favorite IM/Email/whatever client inside of whonix and it will just work”. We got to be there to say “This is the best way, this OK if you really have to, and please don’t do this.”

Yeah, The Tor Project not using Pidgin is a good reason for Whonix not to add Pidgin by default as well.

Their specific Pidgin analysis:
https://lists.torproject.org/pipermail/tor-dev/2013-October/005544.html

TIMB looks interesting:
https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB

I guess when TIMB is out, I can modify Whonix’s update-torbrowser to download it.

Still, even if not installing Pidgin by default, we still could ship that file to deactivate all protocols besides XMPP in case Pidgin gets installed by the user. This would slightly improve security. Also create new support requests, though. And to easily undo this, it would be best if this was a separate pidgin-disable-all-protocols-but-xmpp package.

We could wait for TIMB to mature but that might take a while.

It seems xmpp-client lost the battle (shame, it’s a good idea & implementation) however on the other hand, not being present in Debian is very inconvenient (for now - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740741)

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]