Install Additional Software Safely

From Whonix




Ambox notice.png Qubes-Whonix ™ users need to install and update persistant software [archive] in the Whonix-Workstation ™ TemplateVM(s) (whonix-ws-15).

Using apt-get in the a TemplateBased AppVM (anon-whonix) will only install software for the current session, with changes being lost when the VM is shut down; see Install Software in a TemplateBasedVM.

A primary Whonix ™ goal is to greatly reduce the risk posed by (additional) software installations that are not exclusively designed to work with Tor.

Users can install any software inside Whonix-Workstation ™ using apt-get, since it is based on Debian. However, this is not a recommendation for installing additional software. Also, Whonix ™ is currently the most secure platform for running Tor-unsafe applications like the former Adobe Flash plugin (now deprecated); see the operating system comparison.

The Whonix ™ software page lists:

  • pre-installed Whonix ™ applications which are available for different tasks
  • recommended software for different user activities
  • safety advice
  • installation instructions

Install from Debian stable[edit]

To install a package from Debian stable, follow the steps below. Replace package-name with the name of the software to be installed.

Install package-name.

1. Update the package lists.

sudo apt-get update

2. Upgrade the system.

sudo apt-get dist-upgrade

3. Install the package-name package.

Using apt-get command line parameter --no-install-recommends is in most cases optional.

sudo apt-get install --no-install-recommends package-name

The procedure of installing package-name is complete.

There are numerous examples of this procedure in the Software chapter and throughout the wiki.

Best Practices[edit]

Table: Best Software Installation Practices

Domain Advice
Always Verify Signatures
  • For greater system security, it is strongly recommended to avoid installing unsigned software. Always make sure that signing keys and signatures are correct and/or use mechanisms that heavily simplify and automate this process, like apt-get upgrades.
  • Note: digital signatures are not a magic bullet. While they increase the certainty that no backdoor was introduced by a third party during transit, this does not mean the software is absolutely "backdoor-free". Learn more about this process and what digital signatures prove.
Avoid Manual Software Installation
  • Generally avoid the manual installation of packages, even trusted ones. In practice that means software should only be installed with apt-get, unless special circumstances exist. [1]
  • Other risks: foreign packages are often unsigned, and users may forget to regularly update the software.
Avoid Third Party Package Managers
  • There are many third party package managers besides APT, however many lack the security safeguards that are standard in Debian. Popular examples are pip and node.js.
  • The security concern with third party options is they do not verify the code comes from the author. When used, these package managers run processes that pull untrusted code from the Internet and perform operations with root level permissions.
  • If a trusted Workstation VM is required for sensitive use cases such as a Bitcoin wallet, then completely avoid this option. [2] [3]
Prefer APT
  • The safest option is to stick with Debian's official package manager APT. This is referenced throughout the wiki whenever the user runs apt-get.
  • APT is a secure package manager which passes the TUF threat model, since it features metadata verification and expiration detection. [4] [5]
Prefer Packages from Debian Stable Repository
  • Considering the risks, it is safest to install new software from Debian's stable repository, rather than the testing / unstable or third party repositories -- the Debian FAQ [archive] provides a strong rationale for using the stable repository; see footnote. [6]
  • Only advanced users should attempt to mix packages from Debian testing or Debian unstable. The reason is it can lead to a dependency hell, making it very difficult to resolve the breakage of APT package management.
  • To use newer package versions, see chapter Install Newer Software Versions.


Debian's installation default is --install-recommends. Debian packages have various metadata fields such as:

  • Depends: dependencies or dependency packages
  • Recommends: "recommended" packages
  • Suggests: "suggested" packages

When installing a package using apt-get, dependencies (Depends:) are always installed. The Debian default is for recommended packages (Recommends:) to also be installed alongside the primary package (unless installed previously). To avoid that outcome, it is possible to use the apt-get command line parameter --no-install-recommends; this is in most cases optional.

Debian's default for suggested packages (Suggests:) is --no-install-suggests i.e. not to install suggested packages. Users can optionally use --install-suggests, but there are no known cases where this would be useful at the time of writing. A host of other command line options [archive] are also available.

If a package is installed using apt-get --no-install-recommends install package-name, then re-running apt-get without any parameters or even with --install-recommends will not result in installation of the recommended packages. To accomplish a "late" installation of recommended packages, the simplest method is first uninstalling the package. Alternatively, the list of Recommends: can be viewed using apt-cache package-name or by checking the package on [archive].

A brief Q&A regarding the potential impacts of the "recommended" field is outlined below.

Table: --no-install-recommends Impacts

Question Answer
Can using --no-install-recommends lead to security issues? No. [7]
Can using --no-install-recommends lead to missing or broken functionalities? Yes. For example, mmdebstrap [archive] uses Recommends: and Suggests: for various optional dependencies providing various functionality [archive].
Can omitting --no-install-recommends lead to security issues? In corner cases, yes. For example consider a host operating system without a Host Firewall. [8] By omitting --no-install-recommends -- which defaults in using Debian's default --install-recommends -- packages might be installed that open ports, which can significantly increase attack surface.
Should --no-install-recommends be used? The answer depends on the specific package. Advanced users who know exactly which packages are needed can use --no-install-recommends and afterwards manually add any wanted/additional packages [9] to the apt-get installation command. Otherwise, there might be corner cases of missing optional dependencies or limited functionality.
Should Whonix ™ set the default to --no-install-recommends? [10] This is a good question. It is a big change and could lead to a lot of broken functionality for user-installed packages. At the moment, Whonix ™ user support is manageable because redirection to the Free Support Principle is possible. If --no-install-recommends was the Whonix ™ default, then a lot of functionality might work out of the box in Debian but not in Whonix ™, therefore invalidating the Free Support Principle.

For these reasons, such suggestions should first be raised at Debian's issue tracker after first searching for existing discussions on Debian mailing lists. Search Debian APT issue tracker [archive] for recommend first to avoid duplicate issues. For this change to be implemented, it would probably require a lot of research, good examples and a very well written feature request. [11]

Whonix ™ documentation uses --no-install-recommends whenever appropriate. In general, whether users should use --no-install-recommends for package installation is unspecific to Whonix ™ and should be resolved as per Free Support Principle.

More Security[edit]

General Advice[edit]

Whonix ™ users are free to install their favorite software packages, but should be aware that additional software increases the attack surface [archive] of the platform. Almost any application can be installed, with a few exceptions for programs that are impossible to torify [archive]. In addition, Whonix ™ provides:

Users are responsible for trying to prevent any other protocol leaks [archive] using the "Torify: How-to" guide [archive], but most of those are mitigated by Whonix ™.

apt-get Meta-data[edit]

When updating with apt-get, information will leak about which software packages and versions have been installed, unless Tor onion repositories have been configured. [12] This meta-data cannot be directly linked to any other activity like web browsing, because the Whonix ™ apt-get uwt wrapper forces it to pass through its own circuit. Despite this isolation, it is still possible for updates to be correlated with the same pseudonym. [13] [14]


For greater security when updating:

  • Follow the guidelines below.
  • Be especially careful when adding custom repositories, particularly Personal Package Archives (PPAs).[15] Compared to main distribution repositories, solo developers are more susceptible to influence and theoretically might have malicious intent.
  • Read the protocol leak and fingerprinting protection entry first. It highlights useful information, like the fact that DNS and IP-related leaks do not apply to Whonix ™.
  • Refer to the Tor Project's Torify: How-to [archive] which discusses various protocol leaks [archive] and how to mitigate them.
  • Review the Tor Project's Transparent Proxy Leaks [archive] documentation, which is particularly relevant for Microsoft Windows.

How-to: Install or Update with Utmost Caution[edit]

  1. Stop all activities and shutdown any open applications like Tor Browser.
  2. Change the Tor circuit -- this step may not apply if the user is running an onion service. [16]
  3. Update using apt-get after a random delay. By default, a new Tor circuit is generated after 10 seconds.
  4. Change the Tor circuit again.
  5. Continue user activities after another random period has elapsed.

Whonix-Workstation ™ is Firewalled[edit]

Info Note: This section is relevant to server software or other advanced / uncommon applications.

The Whonix-Gateway ™ firewall [17] has several effects upon Whonix-Workstation ™.

Table: Whonix-Gateway ™ Firewall Effects

Category Notes
Additional Firewall Restrictions The firewall on Whonix-Gateway ™ is very restrictive. It can be made even more restrictive by activating options within the firewall script. [18] It is possible to limit which outgoing ports are redirected to Tor's TransPort. Depending on user intentions, it could also be useful to remove all SocksPorts.
DNS Requests Standard DNS requests on UDP port 53 are redirected to Tor's DnsPort. [19]
Incoming Connections
  • Incoming connections are not supported.
  • If programs make outgoing connections, then incoming connections are accepted for web browsing, IRC, or other relevant applications.
  • Server ports ("open ports") are blocked.
  • Unless explicitly configured, the Ident Protocol / web server listening port is not reachable.
IPv6 Tor only partially supports IPv6 [archive], although full implementation is likely in the near term. [20] This is not a Whonix ™-specific issue. [21]
Server Services Onion Services and/or Location Hidden Services can be hosted.
Tor Routing All traffic originating from Whonix-Workstation ™ and Whonix-Gateway ™ is routed over Tor. [22] [23] [24] [25] [26] [27] [28] Refer to the footnotes for further information.
UDP Tor does not support UDP. This is not a Whonix ™-specific issue.

Related topics:


Install Newer Software Versions[edit]

Info Prerequisite knowledge: refer to the Frozen Packages entry in the Operating System Software and Updates chapter.

It is sometimes possible to install newer versions of software applications, either via available backports or by manual installation. When intending to use newer versions of certain applications like Electrum or Monero it is best to approach the process as an application installation, rather than an application update.

In oversimplified terms, a Debian package is just a vehicle to place files into a location. For example, the binaries-freedom Debian package [archive] in Whonix ™ ships Electrum. It comes with the appimage file (/usr/share/binaries-freedom/electrum-appimage/electrum-4.0.7-x86_64.AppImage) and a start menu entry (/usr/share/applications/electrum-appimage.desktop). The presence of these files does not impose limitations; it is still possible to customize the system and install newer software versions.

These files can also be ignored; for example it is not necessary to use the electrum-appimage start menu entry. The binaries-freedom package is intended to improve usability and it was never designed to limit customization, nor does it have that side effect. As per Whonix ™ policy there are No Intentional User Freedom Restrictions. [29]

As an illustration, a newer version of Electrum would require:

  1. uninstalling binaries-freedom (electrum appimage)
  2. installing Electrum appimage

To install other custom software, it is suggested to follow recommendations throughout this chapter for better security. Specific instructions for custom software installations will vary for each application. This process is mostly unspecific to Whonix ™ and therefore the Free Support Principle applies to installation steps. The same is true for Qubes-Whonix ™ users -- first consider how this process would be achieved in a Debian-based Qubes template.


Debian Backports [archive]:

Backports are packages taken from the next Debian release (called "testing"), adjusted and recompiled for usage on Debian stable.

This is a far safer alternative than the Debian testing or unstable repositories. However, Debian backports should be used conservatively.

Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!

Info Replace package-name below with the package you actually want to install.

package-name can be installed from Debian backports. This is non-ideal, see footnote. [30]

1. Boot Whonix-Workstation ™ (whonix-ws-15) TemplateVM.

2. Add the current Debian stable backports codename buster-backports to Debian apt sources.

Note: this applies to Whonix ™ Later Whonix ™ versions may use a codename different to buster.

In Whonix-Workstation ™ (whonix-ws-15) TemplateVM, run.

sudo su -c "echo -e 'deb tor+ buster-backports main contrib non-free' > /etc/apt/sources.list.d/backports.list"

Alternatively, users who like Onionizing Repositories can set the .onion mirror.

sudo su -c "echo -e 'deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/backports.list"

3. Update the package lists.

sudo apt-get update

4. Install the select software.

sudo apt-get -t buster-backports install package-name

The procedure is now complete.

5. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian buster to bullseye. [31] To proceed, run.

sudo rm /etc/apt/sources.list.d/backports.list

Install from Debian Testing[edit]

Info Mixing packages from Debian stable with those from a later release like testing can destabilize the system due to associated software dependencies required for full functionality.

Before completing steps in this section, first read Prefer Packages from Debian Stable Repository. Carefully check how packages will change before proceeding -- a host of upgrades is usually safe, but no Whonix ™ packages should be removed as part of the process; see Whonix Debian Packages. Be aware that problems are still possible; see here [archive] for an example.

It is recommended to complete this process in a separate Whonix-Workstation ™ (whonix-ws-15-debian-testing-mix) due to the risks. Ask for advice in the forums on a case-by-case basis.

1. Boot the Whonix-Workstation ™ (whonix-ws-15-debian-testing-mix) TemplateVM.

2. Add the current Debian testing codename bullseye to sources.list

Note: this applies to Whonix ™ 15. Later Whonix ™ versions may use a codename different to bullseye.

In the Whonix-Workstation ™ (whonix-ws-15-debian-testing-mix) TemplateVM, run.

sudo su -c "echo -e 'deb bullseye main' > /etc/apt/sources.list.d/testing.list"

Or alternatively use the .onion mirror.

sudo su -c "echo -e 'deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian bullseye main' > /etc/apt/sources.list.d/testing.list"

3. Update the package lists.

sudo apt-get update

4. Install the select software.

sudo apt-get -t bullseye install packagename

  • Replace packagename with the package you actually want to install.

The procedure is now complete.

5. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian buster to bullseye. [32] To proceed, run.

sudo rm /etc/apt/sources.list.d/testing.list

Install from Debian Unstable[edit]

Ambox warning pn.svg.png Managing security updates for the "stable" distribution remains the highest priority for the Debian security team. This means security fixes for Debian "unstable" are managed by the contributors themselves and not by the Debian security team. Therefore, "unstable" does not receive security updates in a timely manner. [33] [34]

Before completing steps in this section, first read Prefer Packages from Debian Stable Repository.

Mixing packages from Debian stable with those from a later release like unstable can destabilize the system due to associated software dependencies required for full functionality. First carefully check how packages will change before proceeding. [35]

A host of upgrades is usually safe, but no Whonix ™ packages should be removed as part of the process; see Whonix Debian Packages. It is recommended to complete this process in a separate Whonix-Workstation ™ (whonix-ws-15-debian-unstable-mix) due to the risk. Ask for advice in the forums on a case-by-case basis.

Ambox warning pn.svg.png Prior to installing package-name [archive] from Debian unstable read Install software from Debian unstable to understand the risks involved and circumvention options. Mixing packages from Debian stable with later release packages like Debian unstable can lead to instability. [36]

1. Open a terminal.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Workstation ™ AppVM (commonly named anon-whonix)Xfce Terminal

If you are using a graphical Whonix with XFCE, run.

Start MenuXfce Terminal

2. In Whonix-Workstation ™ (whonix-ws-15 Qubes-Whonix ™) konsole, add Debian stable codename buster to the apt-conf default-release.

sudo su -c "echo -e 'APT::Default-Release buster;' > /etc/apt/apt.conf.d/70defaultrelease"

3. Add the current Debian unstable codename sid to sources.list.d.

sudo su -c "echo -e 'deb sid main' > /etc/apt/sources.list.d/unstable.list"

Or alternatively use the .onion mirror.

sudo su -c "echo -e 'deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian sid main' > /etc/apt/sources.list.d/unstable.list"

4. Update the package lists.

sudo apt-get update

5. Install package-name from the current Debian unstable codename sid repository.

sudo apt-get install package-name/sid

6. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian buster to bullseye. [37] To proceed, run.

Delete Debian testing repository list.

sudo rm /etc/apt/sources.list.d/unstable.list

Delete apt Default-Release configuration.

sudo rm /etc/apt/apt.conf.d/70defaultrelease

Package Reinstallation[edit]

As per the free support principle, package reinstallation utilizes normal Debian processes.

The example below shows how the thunderbird package would be reinstalled. It is possible to substitute thunderbird with many other packages, so long as they do not have too many dependencies. These instructions are not suitable for any packages needed for connectivity such as tor, because the reinstallation would be very difficult and is currently unsupported.

Even in the thunderbird package example, dependency complications emerge. The anon-workstation-packages-recommended package also depends on thunderbird. Further, the whonix-workstation package depends on anon-workstation-packages-recommended.

1. Update the package lists and upgrade.

See Updates for instructions.

2. Purge the package you want to reinstall.

sudo apt-get purge thunderbird

The output will show something like the following.

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  anon-workstation-packages-recommended* thunderbird* whonix-workstation*
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
After this operation, 90.8 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 100681 files and directories currently installed.)
Removing whonix-workstation (3:2.9-1) ...
Removing anon-workstation-packages-recommended (3:2.9-1) ...
Removing thunderbird (38.4.0esr-1~deb8u1) ...
Purging configuration files for thunderbird (38.4.0esr-1~deb8u1) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
Processing triggers for menu (2.1.47) ...
Processing triggers for man-db ( ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for qubes-core-agent (3.0.20-1+deb8u1) ...
Processing triggers for mime-support (3.58) ...

The packages anon-workstation-packages-recommended and whonix-workstation have been inadvertently uninstalled due to technical limitations. [38] These packages are reinstalled at a later step.

3. Delete the user configuration folder if that is desired.

In this thunderbird example, the user configuration folder is specified below (it changes depending on the package).

rm -r ~/.thunderbird

4. Reinstall the thunderbird package and the additional packages that were purged.

The --no-install-recommends parameter below is optional.

sudo apt-get install --no-install-recommends thunderbird anon-workstation-packages-recommended whonix-workstation

Related to: Whonix Debian Packages.

Install Software in a TemplateBasedVM[edit]

Info Qubes-Whonix ™ only! Custom scripting is recommended, which is beyond the scope of this entry. Use a search engine to locate free articles and instructions on this process.

There is no reason to avoid installing software in TemplateBasedVMs [archive], although installed software will not persist across reboots. A custom script can be used to automate this process, which minimizes the time spent re-installing packages.


This software installation method means a single VM [archive] assumes many of the positive characteristics found in both TemplateBasedVMs and StandaloneVMs [archive].

  • Centralized Updates: AppVMs [archive] are based on a TemplateVM [archive]. This means the AppVM's root filesystem is based on the corresponding template's root filesystem. Any updates to the TemplateVM will be reflected in the TemplateBasedVM's root filesystem upon restart.[39]
  • Minimal Disk Usage: TemplateBasedVMs require much less disk space than StandaloneVMs, since the AppVM's root filesystem is based on the corresponding template. The AppVM only needs enough disk space to hold user files in the /home directory.
  • Semi-persistent Storage: User data stored in /home , /rw and /usr/local survives reboot. Many applications like Signal [archive] and Wire [archive] store user data in the /home folder. Since the custom script installs the software seamlessly with little or no user interaction, the AppVM has "quasi-full persistence", not unlike a StandaloneVM's full persistence.

AppVM Preparation[edit]

1. Create an AppVM based on whonix-ws-15.

2. Pre-install any necessary dependencies.

Dependencies are available from [archive] and can be pre-installed in the TemplateVM to speed up the repetitive software installation process. This means only packages or software missing from [archive] will be repeatedly installed in the AppVM.

3. Create a custom script that runs at VM boot.

The purpose of this script is to automate software installation that would otherwise require manual user steps. Note that script functionality is variable, dependent on the software packages being installed and the experience of the user.

Scripting is useful for common tasks like:

  • adding specific software repositories
  • importing verified signing keys
  • updating the package list with apt-get update, after the repository and signing key are imported
  • finally running apt-get install to install the relevant software package(s)

AppVM Use[edit]

Ambox warning pn.svg.png The AppVM's root filesystem does not provide a strong non-persistent security feature [archive]. The persistence of the /home, /rw, and /usr/local filesystem means malware can be specifically written to target Qubes-based AppVMs, inserting hooks inside these directory's files. [40] [41]

Once user preparation is complete and the AppVM has started, it will automatically start the script to begin installing software. When the process finishes, the AppVM can be used like any other TemplateBasedVM. However when the AppVM is shutdown, all data outside of the persistent /home folder will be lost, including the newly installed software packages. Following reboot, the VM will again install the software packages automatically.

Using bind-dirs Selective Persistence[edit]

Using selective bind-dirs [archive] persistence is currently a difficult problem and undocumented. Further research is required to ascertain which files require persistence across VM reboots.

Add Application Launcher to Start Menu[edit]

1. Create folder ~/.local/share/applications.

mkdir -p ~/.local/share/applications

2. Create a new file ~/.local/share/applications/program-name.desktop using an editor.

mousepad ~/.local/share/applications/program-name.desktop

3. Paste the following contents.

[Desktop Entry]

4. Save the file.

The procedure is now complete.

The launcher can be found here:

Start MenuOtherprogram-name


General forum discussion about snap: Snap Store / snaps / snapd / - a new software source? [archive]

Qubes-Whonix ™ issues:


flatpak Package Manager Security[edit]

This entry compares flatpak security features (such as signed metadata) against Debian's APT package manager. [43] With one caveat, flatpak package manager security is comparable to Debian's APT package manager: Flatpak currently does not defend against indefinite freeze attacks [archive].

A definition of indefinite freeze attacks is provided by TUF (The Update Framework) Threat Model [archive]:

An attacker continues to present files to a software update system files that the client has already seen. As a result, the client is kept unaware of new files.

For many adversaries this attack is difficult because it requires breaking TLS. While flatpak package version information is not protected by a valid-until field [archive], it is fetched over TLS. Adversaries capable of breaking TLS face an obstacle when dealing with torified connections (like those in Whonix ™) -- an indefinite freeze attack cannot target a specific user, but will affect all Tor users. This increases the chances of being caught unless they also have the ability to break Tor. Even then the attack chain would be very complex: Break TorTarget specific user(s)Break TLSMount an indefinite freeze attackExploit a vulnerability caused by an outdated software version.

To safeguard against this possibility, it is recommended to perform manual checks of version numbers for flatpak-installed applications -- they should match those available from the flathub repository. Every flathub application has a corresponding website page with an Additional information section that lists Updated and Version information. For example, at the time of writing for Chromium:

Researching version information on the flathub website with a browser is equally vulnerable to indefinite freeze attacks because it also relies upon TLS. It is therefore recommended to use Whonix ™ or Tor Browser for this purpose. [44]

Sometimes APT software versions are quite old, which can lead to less functionality or even exposure to known vulnerabilities that are being exploited in the wild (see footnote). [45] Conversely, flatpak usually offers more recent software versions and/or deploys security fixes in a more timely manner.

In summary, flatpak advantages are considered to outweigh the potential risks of an indefinite freeze attack because the attack chain is complex. Also, flatpak is sometimes the only trustworthy, easy-to-use software source that provides newer versions than available in Debian stable (with Frozen Packages) (or newer).

Forum discussion:

Qubes OS Specific[edit]

At the time of writing, applications installed using flatpak do not present in the Qubes start menu. [46]
Workaround: navigate to Qube settingsapplications tabpress "Refresh Applications".

Foreign Sources[edit]

For most use cases the extensive software range available from the official Debian repositories should be sufficient. A selection of nearly 60,000 programs [47] can be installed within a couple of steps. These packages are constantly maintained for bug/security fixes and are tightly integrated to provide a stable distribution.

To guarantee stability, no new versions are uploaded to Debian stable archives to avoid breaking the system. This makes Debian stable a dependable distribution and an excellent base for downstream distributions. However, the Linux software scene is very dynamic and sometimes users will want software that is not yet packaged in Debian. In this case it may be necessary to install software from separate sources; either from third party repositories, as a stand-alone precompiled .deb binary, or directly compiled source packages. [48]


Foreign sources should be used infrequently because it can cause problems. Note this is simply a warning about the worst case scenario and not a predetermined outcome of installing third party software.

Security Issues[edit]

Foreign sources pose important security implications for the affected system. Installing software is tantamount to granting root privileges to the developers. Software originating from dubious sources could replace important system components with malicious versions that allow backdoors or Trojan horses [archive] to be installed on the system.

In general, the installation of software is a matter of trust. The fact is every installed software source must be trusted. This trust is two-fold: firstly that the developers have integrity, and secondly that the community will notice any suspicious code, which might indicate compromise of the developers' machines. [49]

Dependency Hell[edit]

Manually installed packages can contain library versions that are unavailable in the standard repositories. This causes problems with dependency resolution when installing additional software from the official repository. Individual applications are less critical in this context, but when important system libraries in the third-party software are considered, complications are inevitable.

Depending on the severity of the complications, upgrades to the next version of the operating system might fail, or the system may become unbootable or generally unstable.


Users can reduce security risks and eliminate the risk of making the workstation unusable by using Multiple Whonix-Workstation ™.

GUI Applications with Root Rights[edit]

Moved to Safely Use Root Commands: Graphical Applications with Root Rights.


  1. Such as desirable software versions that are not yet bundled in the official repositories.
  2. [archive]
  3. The pip developers refused to implement any kind of proper GPG signature verification, opting to support server HTTPS instead [archive] which is a lot weaker. While the TUF secure updater project has implemented a safe version of pip [archive], it is not clear how widely it has been adopted and whether it will become popular.
  4. [archive] [archive]
  5. [archive]
  6. If security or stability are at all important for you: install stable. period. This is the most preferred way.

    ... Since there is typically over 1 year between releases you might find that stable contains old versions of packages. However, they have been tested in and out. One can confidently say that the packages do not have any known severe bugs, security holes etc., in them. The packages in stable integrate seamlessly with other stable packages. These characteristics are very important for production servers which have to work 24 hours a day, 7 days a week. ... Stable is rock solid. It does not break and has full security support. But it might not have support for the latest hardware.

    On the other hand, packages in testing or unstable can have hidden bugs, security holes etc. Moreover, some packages in testing and unstable might not be working as intended.

  7. There are no known examples at the time of writing.
  8. Most people nowadays are behind a NAT router which blocks unsolicited incoming connections by default. While that protects from outside Internet-based attacks, it does not protect against attacks launched from inside the local area network (LAN) (devices that use the same router). This is specifically dangerous when using shared WiFi hotspots.
  9. Perhaps including some recommended packages.
  10. See: set apt-get --no-install-recommends by default [archive]
  11. This wiki chapter has been authored so it may be a useful resource in the future.
  12. See software updaters [archive] for more information on this topic.
  13. Consider the following example. A user announces online that software X is being utilized, and another specific application set x, y, and z is installed. If this information becomes available to an adversary and the circuit-isolated apt-get passes through any Tor exit relays, mirrors or ISPs under their control, then they may guess it is associated with the same pseudonym. In that case, the adversary has a list of the user's installed packages, and can attempt a stale mirror attack (if the user has a custom Ubuntu build), or try other attacks against apt-get.
  14. As per the previous footnote, this threat equally applies to users who run an onion service with a specific set of server software, for example apache, mediawiki, phpbb, and others.
  15. Using PPA in Ubuntu Linux (Complete Guide) [archive]:

    PPA stands for Personal Package Archive. The PPA allows application developers and Linux users to create their own repositories to distribute software. With PPA, you can easily get newer software version or software that are not available via the official Ubuntu repositories.

  16. One option is using Arm: Navigate to Whonix-Gateway ™ (Qubes-Whonix ™: sys-whonix)Select Arm - Tor ControllerPress "n" for a New Identity.
    Alternatively: Press "m" for the menuScroll down to "New Identity"Press "Enter".
  17. The firewall is found on Whonix-Gateway ™: /usr/bin/whonix_firewall
  18.          ## Optionally restrict TransPort.
             ## Replace above rule with a more restrictive one, e.g.:
             #$iptables_cmd -t nat -A PREROUTING -i "$int_if_item" -p tcp --match multiport --dports 80,443 --syn -j REDIRECT --to-ports "$TRANS_PORT_WORKSTATION"
  19. If the DNS server is changed in Whonix-Workstation ™ /etc/resolv.conf, this will likely have no effect. The reason is the firewall on Whonix-Gateway ™ will redirect all those requests to Tor's DnsPort. The working exception to this rule is when users tunnel / encrypt DNS requests (DNSCrypt, httpsdnsd), as per the secondary DNS resolver instructions.
  20. The only missing elements at the time of writing were automatic client connections and inter-relay connections via IPv6. Bridges are fully supported. See also: IPv6 roadmap [archive].
  21. [archive]
  22. Since Whonix ™ version 0.2.1 Whonix-Gateway ™ traffic is also routed over Tor. In this way, use of Whonix is hidden from persons or systems observing the network.
  23. To preserve the anonymity of a user's Whonix-Workstation ™ activities, it is not necessary to torify Whonix-Gateway ™ own traffic.
  24. For reader interest: If DNS settings on Whonix-Gateway ™ are changed in /etc/resolv.conf, this only affects Whonix-Gateway ™ own DNS requests issued by applications using the system's default DNS resolver. By default, no applications issuing network traffic on Whonix-Gateway ™ use the system's default DNS resolver. All applications installed by default on Whonix-Gateway ™ that issue network traffic (apt-get, whonixcheck, sdwdate) are explicitly configured, or forced by uwt wrappers, to use their own Tor SocksPort (see Stream Isolation).
  25. Whonix-Workstation ™ default applications are configured to use separate Tor SocksPorts (see Stream Isolation), thereby not using the system's default DNS resolver. Any applications in Whonix-Workstation ™ that are not configured for stream isolation - for example nslookup - will use the default DNS server configured in Whonix-Workstation ™ (via /etc/network/interfaces), which is the Whonix-Gateway ™. Those DNS requests are redirected to Tor's DnsPort by Whonix-Gateway ™ firewall. Whonix-Gateway ™ /etc/resolv.conf does not affect Whonix-Workstation ™ DNS requests.
  26. Traffic generated by the Tor process itself which runs by Debian default under user debian-tor originating from Whonix-Gateway ™ can use the internet normally. This is because user debian-tor is exempted in Whonix-Gateway ™ Firewall, allowed to use the "normal" internet.
  27. The Tor software (as of (and no changed were announced at time of writing) almost exclusively uses TCP traffic. See also Tor wiki page, chapter UDP. For DNS, see next footnote.
  28. Tor does not require, use functional (system) DNS for most functionality. IP addresses of Tor directory authorities are hardcoded in the Tor software as per Tor upstream default. Exceptions include:
    • proxy settings using proxies with host names rather than IP addresses
    • the Tor pluggable transport meek lite to resolve domains used in setting url=, front= to IP addresses.
  29. In simple terms, Whonix modifications can be ignored.
  30. Users should Prefer Packages from Debian Stable Repository, but using backports is better than manual software installation or using third party package managers since this prefers APT. To contain the risk, Non-Qubes-Whonix ™ users might want to consider using Multiple Whonix-Workstation ™ and Qubes-Whonix ™ users might want to consider using Multiple Qubes-Whonix ™ TemplateVMs or Software Installation in a TemplateBasedVM.
  31. Most often this step applies before attempting major Whonix ™ upgrades; upgrade instructions are also made available at that time (see Stay Tuned).
  32. Most often this step applies before attempting major Whonix ™ upgrades; upgrade instructions are also made available at that time (see Stay Tuned).
  33. [archive]
  34. [archive]
  35. See: [archive]
  36. It is recommended to create aMultiple Whonix-Workstation ™ to install the package due to these risks.
  37. Most often this step applies before attempting major Whonix upgrades; upgrade instructions are also made available at that time (see stay tuned).
  38. Whonix_Debian_Packages#Technical_Stuff
  39. Qubes install software [archive]
  40. [archive]
  41. Obvious hook targets include .bashrc, the Firefox profile directory (which contains extensions), or PDF or DOC documents that are likely to be opened by the user.
  42. APT works because of Qubes' qrexec-based updates proxy.
  43. Note that source code is not considered in this comparison.
  44. In theory some adversaries are capable of mounting an indefinite freeze attack against all visitors arriving from the Tor network. This is considered unlikely because the threat of eventual detection is too high. Such an attack would be widely publicized and might lead to major improvements in how Internet encrypted/authenticated connections are established.
  45. Chromium exploitation example.
  46. flatpak installed applications do not show up in Qubes start menu [archive]
  47. [archive]
  48. [archive]
  49. With reproducible package builds on the horizon, the security risk from the second factor will be minimal in the future.

Fosshost is sponsors Kicksecure stage server Whonix old logo.png
Fosshost About Advertisements

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki

Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png link=mailto:?subject=Install Software&body= link= Software link= Software link= Software%20 Software

Love Whonix ™ and want to help spread the word? You can start by telling your friends or posting news about Whonix ™ on your website, blog or social media.

https link onion link Priority Support | Investors | Professional Support

Whonix | © ENCRYPTED SUPPORT LP | Heckert gnu.big.png Freedom Software / Osi standard logo 0.png Open Source (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.