Whonix Default Application Policy

From Whonix
< Dev
Jump to navigation Jump to search

Design Documentation - How to decide which apps come with Whonix?

How to decide which apps come with Whonix?[edit]

if available from packages.debian.org[edit]

Overall: not killing the project for being badmouthed by The Tor Project and/or geeks due to bad decisions.

The following numbers are not referring to priorities, just to reference them. Not written in stone!

Important hopefully mostly objective requirements:

  1. There must be a reliable upgrade path. Stuff that is in Debian is perfect.
  2. Upgrading must not eat up Whonix contributor's time to keep Whonix maintainable.
  3. If the applications issues network activity, there must be a way to properly configure it for Stream Isolation, to keep Tor's TransPort clean for the user's own stuff. (https://forums.whonix.org/t/should-strict-stream-isolation-by-a-requirement-in-whonixs-default-application-policy/3940archive.org Deprecated)
  4. When downloading applications, especially since downloads run over Tor, strong verification must be supported (Ex: OpenPGP, APT does that well.) or be so trivial that some trusted devs can audit the code for being not intentionally malicious.
  5. Must be Tor-safe. (Definition: must not be totally pseudonymous. No major protocol leaks. For example, using Tor Browser instead of Firefox.)
  6. Must be Freedom Software / Open Source.
  7. Must not be a total security disaster.
  8. Must not issue network activity while the application is not in use.
  9. Installation/modification must not limit discussion about Whonix to the controversy of that application. (Ex: No Tor modifications.)
  10. Installing it by default in Whonix must not totally f*ck up The Tor Project.

Less important hopefully mostly objective requirements:

  • We must believe that a fair amount of users likes it.
  • We must believe that it is usable by a fair amount of users.
  • Mature behaving and communicative upstream, not important if the application/script is trivial and maintenance is simple.

Contradictions and subjective influences:

  • It's not possible to have perfectly logical, rational, consistent decisions.
  • Discussions on default installed applications are prone to law of triviality / bikeshedarchive.org.
  • Selection is a shadow of the preference of the contributors of Whonix.
  • Requests by supporters of Whonix weight higher in relation to their contribution.
  • A degree of arbitrariness.
  • Disagreements are to be expected. There are hundreds or thousands of Linux distributionsarchive.org. See this imagearchive.org to get a feeling on how many software forksarchive.org exist. With the growth of popularity of a Linux distribution it is to be expected that disagreements arise and forks happen.

Manually installed by default software would be nightmare for reasons explained in this chapter.


a) There is no torrent client installed by default in Whonix, because we know of none fulfills point number 3. If one has been found, this topic has to be brought up on tor-talk mailing list, asking for their official position, due to contradictory prior statements to fulfill 10.

if not available from packages.debian.org[edit]

The conditions from chapter #if available from packages.debian.org apply. On top of these, the following conditions apply.

  • Few (security) updates required. Low maintenance overhead. Must not eat up Whonix contributor's time to keep Whonix maintainable.
  • Much higher requirement in popular demand compared to as if the software was available from packages.debian.org.
  • Packaging difficulty.
    • For example in case of electrum an AppImage was available, which is a self-contained binary independent from any other dependencies on the system. Technically easy to add.
    • Less but still a chance: Applications available as from a third party deb package repository have higher chance.
    • Less but still a chance: Software that is available for direct deb package download.
    • Dependencies: the more complicated / unforgiving the dependencies are, the less likely. The less picky dependencies, higher chances.
    • Complex software not packaged yet has smallest chances of inclusion.
  • Security: Upstream developers must digitally sign their software (therefore support Verifying Software Signatures.) An exception could be made for software that has so little or so easy source code that it can be easily reviewed by Whonix project.

See also package binaries-freedomarchive.org and related forum discussion Policy for Inclusion of Compiled Softwarearchive.org.

Package Origin[edit]

Compiled Software[edit]

From APT Package Sources[edit]


packages.debian.org gives us:

  • always stable, not breaking stable, a contributor testing the package with Debian
  • some vetting that the package does not contain an obvious backdoor
  • easily installable without much long term time sunk from developer side, just add once to anon-meta-packages and be done with it
  • no extra repository signing keys (that have the ability to replace any package on the system), if we theoretically added something like deb.gnunet.org, if they were compromised, all Whonix users would be compromised at once through an malicious upgrade. That's how Debian works. All packages have full system access. No sandboxing.
  • no need for to follow up on security issues of the package, no quick security fix uploads, all done by Debian.
  • no time sunk as in reuploading new packages to deb.whonix.org.
    • no download from the vendors website
    • no verification of signature from the vendors website
    • no upload / install test from developers repository [a broken package could break the whole system, not in malicious ways, but for example broken connectivity that cannot be restored without hacking command into a console]
    • no upload / install test from testers repository, have more people try to run into such issues
    • no migrate to stable repository
    • no remember the state, bug reports, look if it was actually tested of the whole thing
    • it is not very difficult technically, but demanding on mental resources and time, without a dedicated release manager, it is better to pick to pick fewer "special" packages from other sources than packages.debian.org


The tor [1] package is downloaded from deb.torproject.org and uploaded to deb.whonix.org by Whonix developers. [2] Reasons:

  • One of the most crucial components of Whonix.
  • Compatibility with latest stable version Tor Browser. Why compatibility with Tor Browser is a goal is documented in this chapter.
  • Other reasons.

A maintenance intense task.

From Non-APT Package Sources[edit]


There are issues with security as well as maintenance overhead.

Security issues are mentioned in chapter Best Practices which include:

  • Prefer APT
  • Avoid Third Party Package Managers
  • Avoid Manual Software Installation
  • Always Verify Signatures
  • Prefer Packages from Debian Stable Repository

All of above are explained in greater detail in chapter Best Practices.


Tor Browser

Anonymous web browsing is one of the most if not the most popular task when using Whonix or Tor. For usability and crucial anonymity reasons it is required to easily make the latest stable version of Tor Browser available in Whonix. The Tor Browser page describes this in greater detail. Due to issues outside of control of Whonix, there is no APT package source providing Tor Browser. See this chapter for more details on that.

Therefore tb-updaterarchive.org is being used to install Tor Browser by default in Whonix from dist.torproject.org.

It can be easily kept up to date by Tor Browser internal updater as well as Tor Browser Updater (Whonix) as documented on the Tor Browser page.

Historically one of the biggest sources of development work because tb-updater broke as Tor Project applied changes to Tor Browser and its download location and therefore also one of the biggest sources of support requests.


Installing software other then Tor Browser (as documented above) from non-APT package sources by installed one by default would be nightmare, because:

  • Users wouldn't know how it was installed and not update it.
  • Updating would be left to the user.
  • It is better if the whole process of download, verification, install, upgrade notification and upgrade is up to the user.

Experiences made with tb-updater and Tor Browser (see above chapter) further discourage this.

Shipping Compiled Software in Binary Packages[edit]

Forum discussion: https://forums.whonix.org/t/policy-for-inclusion-of-compiled-software/6635archive.org


  • none

Future candidates for inclusion into binaries-freedom package:

Source Package[edit]

Uploading Source Packages to deb.whonix.org[edit]

Usability wise not very useful. Users could download and compile source packages. As far as I know there is no install/upgrade mechanism for source packages. Even if there was, they would not auto compile and upgrade. Would require quite some documentation. apt source pkg-name, cd pkg-name, install build dependencies, install dependencies, build, install. More support overhead. Plus almost same issues as for binary packages.


GNU Guix is a compromise between tracking/maintaining the dependency hell of a non-Debian program or completely excluding them for that reason.

By including and maintaining Guix as a gateway into instead we cut down the effort needed to obtain external programs for us and for the program devs too.

Brief Intro: In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection (more details in the manual.) [3]

Where to download? How to verify? How to install? (Any compilation required?)

Download here: https://www.gnu.org/software/guix/download/archive.org

Verification and install instructions: https://guix.gnu.org/manual/en/html_node/Binary-Installation.htmlarchive.org

No compilation required. A signed binary tarball is distributed. The binary installation tarball can be (re)produced and verified simply by running the following command in the Guix source tree:

make guix-binary.system.tar.xz

Full manual: https://www.gnu.org/software/guix/manual/guix.htmlarchive.org

There is also an installation script:


At time of writing, the installation script does not pass the TUF (The Update Framework)archive.org (githubarchive.org) threat model. [4] [5]

Installable from packages.debian.org using APT?

Not yet. Maybe in Debian bullseye:



Any ready-made repositories available that we can start using? Like, if one manages to install Guix on Debian or Whonix, what packages can be installed? How does that work in practice?

The Guix library is made of ~5K packages. They carry Libre packages only: https://www.gnu.org/software/guix/packages/archive.org

Packages are installed with:

guix package -i hello

Any onion repositories?

No. I think they might be open to running one. I can talk with them and the Tor people to make it happen.

Update: Planned with serious discussions happening around this topic. https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.htmlarchive.org

Does it pass TUF's threat model?

Not yet but being worked towards and should be there by v.1.0


Update: Was this done?

Socks proxy support or can torsocks work?

Package configuration definitions include support for defining network access including redirecting traffic to Tor. Manual example:

Scheme Procedure: tor-service [config-file] [#:tor tor]

   Return a service to run the Tor anonymous networking daemon.
   The daemon runs as the tor unprivileged user. It is passed config-file, a file-like object, with an additional User tor line and lines for onion services added via tor-hidden-service. Run man tor for information about the configuration file.


How does its sandboxing work and why is it secure?

Not sandboxing as in Apparmor isolation but the ability to build/install/upgrade software without requiring root ever. Guix packages can also be shared among unprivileged user profiles.

Any example packages?

There is the hello package as an example or any of the ones listed in the directory mentioned above(?)

Info on making packages:


How to create a repository?

In the manual there is support for fetching source from git repositories and building that. So potentially any git repo can act as a decentralized package hosting. Edit: I can confirm that all packages in their package list are indeed git repos hosted on savannah.

All packages and their dependencies are available in the Guix main collection.

Interesting reading: https://arxiv.org/pdf/1305.4584.pdfarchive.org


  1. binary and source package
  2. Function get_tpo_packages in https://github.com/Whonix/derivative-maker/blob/master/build-steps.d/2100_create-debian-packagesarchive.org
  3. https://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg00000.htmlarchive.org
  4. The Update Framework (TUF) - Threat Model - Attacks and Weaknesses - https://theupdateframework.io/security/archive.org -
  5. The following source code using gpg for verification of software signature is vulnerable to rollback attacks and indefinite freeze attacks.
        gpg --verify "${bin_ver}.tar.xz.sig" >/dev/null 2>&1
        if [[ "$?" -eq 0 ]]; then
            _msg "${PAS}Signature is valid."
            popd >/dev/null
            _err "${ERR}could not verify the signature."
            exit 1

    See also gpg-bash-libarchive.org.

    The installation script is also vulnerable to endless data attacks and slow retrieval attacks.

    Minor: It uses wget which has a buggy TLS certificate verificationarchive.org instead of secure curl.

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!