Install Additional Software Safely

Whonix ®

Download

Windows Linux Mac VirtualBox KVM Qubes Intel / AMD64 ARM64 PPC64 USB ISO Raspberry Pi More options Source Code

About

Overview Features Whonix vs VPNs Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Release Upgrade Documentation sysmaint Previous page: Release Upgrade Index page: Documentation Next page: sysmaint Install Additional Software Safely

• Updates
• Install Additional Software
• Software Recommendations
• Point Release
• Release Upgrade

This wiki page provides guidance on how to install additional software on the Whonix operating system using security best practices,

Introduction

Whonix is based on Debian. The software installation process is unspecific to Whonix. This means that most Debian software can be installed on Whonix, exactly the way you would install it on Debian. It should work out of the box. You can also check for tutorials on how to install software on Debian and apply them to your Whonix software needs. In most cases, there is no need to ask how to install specific software on Whonix because it is better to resolve the question as per the Self Support First Policy. In case of issues, the user is advised to attempt Generic Bug Reproduction. Only in rare cases will there be Whonix specific issues requiring Support.

For recommended software for various daily tasks, compiled by the Whonix team, visit the Whonix software page. There you will find

• Pre-installed Whonix applications which are already available for different tasks.
• Recommended software for different user activities.
• Installation instructions.
• Security advice regarding software.

Below you will find instructions on the installation process, divided into different user qualifications.

Platform Specific Notices

Before we start here are some platform specific notices.

Platform specific. Select your platform.

Whonix users:

• No special notice.

Qubes-Whonix^™ users:

• The following notices describe the general technical implementation for all (including non-Whonix templates) and are unspecific to Whonix.
• Need to install and update persistent software in the Whonix-Workstation^™ Template(s) (whonix-workstation-17).
  • Learn more about Qubes Persistence.
• Using APT in the App Qube (such as for example anon-whonix) will only install software for the current session, with changes being lost when the VM is shut down; see Install Software in an App Qube.

All Users instructions (Novice, Easy)

Package Installation from Debian Package Sources

Install from Debian stable: The easiest and best way to install software is from Debian stable APT software repository.

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(s) package-name following these instructions

1 Platform specific notice.

• Non-Qubes-Whonix: No special notice.
• Qubes-Whonix: In Template.

2 Update the package lists and upgrade the system.

sudo apt update && sudo apt full-upgrade

3 Install the package-name package(s).

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

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

4 Platform specific notice.

• Non-Qubes-Whonix: No special notice.
• Qubes-Whonix: Shut down Template and restart App Qubes based on it as per Qubes Template Modification.

5 Done.

The procedure of installing package(s) package-name is complete.

Examples: There are numerous examples of this procedure on the Software page and throughout the wiki.

Re-Install Package

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

Related: Reset Configuration Files to Vendor Default

Advanced Users instructions

These instructions are for more advances users who have experience with Linux operating systems.

Install Newer Software Versions

It is sometimes possible to install newer versions of applications. Newer versions than the versions which are available through Operating System Software and Updates. But this is in most cases:

• Often not required for security reasons due to Frozen Packages.
• Only a user customization activity done by a user who wishes to use newer features of applications.

Prerequisite knowledge: refer to the Frozen Packages and Application Specific Update Indicators entries in the Operating System Software and Updates chapter.

Due to general usability issues of all Linux distributions (which are unspecific to Whonix), this activity is for advanced users only.

Difficulty: medium / hard, depending on the application.

It is sometimes possible to install newer versions of applications, via any of the following installation methods (non-exhaustive list):

• A) alternative official Debian APT repositories such as
  • backports,
  • fasttrack,
  • testing,
  • unstable,
• B) third party provided Debian APT repositories
• C) alternative installation methods such as
  • flatpak,
  • snap,
• D) or by manual installation from:
  • extraction from a compressed archive file,
  • installation of a .deb package,
  • source code.

The user is trading one security advantage (installing most software only from Debian repositories) against other security advantages (newer software versions) and disadvantages (trusting another software source). Foreign Sources come with Risks.

Availability depends on the installation methods which either Debian, a derivative (such as Whonix) or the upstream (original) application developers made available.

To install other custom software, it is suggested to follow recommendations throughout this website for better security. Specific instructions for custom software installations will vary for each application. This process is mostly unspecific to Whonix and therefore the Self Support First Policy applies to installation steps. The user would have to Utilize Search Engines and Documentation and research how this process would be achieved in Debian version bookworm, which Whonix is currently based on. The same is true for Qubes-Whonix users -- first consider how this process would be achieved in a Debian-based Qubes template.

When intending to use newer versions of certain applications like Electrum, 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 in Whonix used to ship Electrum. It came 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 such files, as in this example, does not impose limitations; it is still possible to customize the system and install newer software versions.

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

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

1. Uninstalling the electrum package (Optional and best avoided. Prerequisite knowledge: Debian Packages).
2. Finding out the real website of Electrum (avoid downloading malicious money-stealing software forks from scammers).
3. Downloading the Electrum compressed archive from upstream (original developers).
4. Optional but highly recommended digital software verification of the downloaded Electrum.
5. Extracting the Electrum compressed archive.
6. Changing directory into the extracted Electrum folder.
7. Starting Electrum from the command line.
8. Optional beautifications such as adding start menu entries or autostart.

Enable Debian Backports Repository

Operating System Specific Notes:

• Whonix VM users: Should skip this step! Debian APT backports repository is already default in Whonix version 16 and above.
• Debian: The following instructions are for Debian host operating system or Debian VM users.

1. Boot the virtual machine. (Qubes: debian-12 Template).

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

Notes:

• This applies to Debian 17. Later Debian versions will use a codename different to bookworm.
• Advanced users note: Instructions for torification of the fasttrack clearnet repository or fasttrack onion repository can be found in the following footnote.

Run.

sudo su -c "echo -e 'deb https://deb.debian.org/debian bookworm-backports main contrib non-free' > /etc/apt/sources.list.d/backports.list"

3. Done.

The procedure of enabling Debian backports repository has been completed.

4. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian bookworm to trixie. To proceed, run.

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

Enable Debian Fasttrack Repository

Operating System Specific Notes:

• Whonix VM users: Should skip this step! Debian APT fasttrack repository is already default in Whonix version 16 and above.
• Debian: The following instructions are for Debian host operating system or Debian VM users.

1. Boot the Debian VM. (Qubes: debian-12) Template.

2. Install the fasttrack-archive-keyring package.

Install package(s) fasttrack-archive-keyring following these instructions

1 Platform specific notice.

• Non-Qubes-Whonix: No special notice.
• Qubes-Whonix: In Template.

2 Update the package lists and upgrade the system.

sudo apt update && sudo apt full-upgrade

3 Install the fasttrack-archive-keyring package(s).

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

sudo apt install --no-install-recommends fasttrack-archive-keyring

4 Platform specific notice.

• Non-Qubes-Whonix: No special notice.
• Qubes-Whonix: Shut down Template and restart App Qubes based on it as per Qubes Template Modification.

5 Done.

The procedure of installing package(s) fasttrack-archive-keyring is complete.

3. Add the current Debian fasttrack APT repository.

Notes:

• This applies to Debian 17. Later Debian versions will use a codename different to bookworm.
• Advanced users note: Instructions for torification of the fasttrack clearnet repository or fasttrack onion repository can be found in the following footnote.

Run.

sudo su -c "echo -e 'deb https://fasttrack.debian.net/debian/ bookworm-fasttrack main contrib non-free' > /etc/apt/sources.list.d/fasttrack.list"

4. Done.

The procedure of enabling Debian fasttrack repository has been completed.

5. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian bookworm to trixie. To proceed, run.

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

Backports

Debian Backports:

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!

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.

1. Update the package lists.

sudo apt update

2. Install the select software.

sudo apt -t bookworm-backports install package-name

3. Done.

The procedure of installing the package from the backports repository is now complete.

System-Wide Upgrade to Backports

Discouraged.

No, even though backports are enabled by default in Whonix, by Debian default, APT does not upgrade all packages to the backports version by default. See footnote for evidence.

How? See footnote. </ref>

Fasttrack

Debian Fasttrack:

Debian Fast Track is a repository that allows making “backports” of packages available to users of the stable distribution, if those packages cannot be maintained in testing and backported in the usual way.

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

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!

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

package-name can be installed from Debian fasttrack. This is non-ideal.

1. Update the package lists.

sudo apt update

2. Install the select software.

sudo apt -t bookworm-fasttrack install package-name

3. Done.

The procedure of installing the package from fasttrack is now complete.

Install from Debian Testing

Warnings

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 for an example.

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

Procedure

1. Boot the Whonix-Workstation (whonix-workstation-17-debian-testing-mix) Template.

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

Note: this applies to Whonix 16. Later Whonix versions may use a codename different to trixie.

In the Whonix-Workstation (whonix-workstation-17-debian-testing-mix) Template, run.

sudo su -c "echo -e 'deb https://deb.debian.org/debian trixie 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 trixie main' > /etc/apt/sources.list.d/testing.list"

3. Update the package lists.

sudo apt update

4. Install the select software.

• Note: Replace package-name with the package you actually want to install.

sudo apt -t trixie 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 bookworm to trixie. To proceed, run.

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

Install from Debian Unstable

Warnings

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.

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.

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-workstation-17-debian-unstable-mix) due to the risk. Ask for advice in the forums on a case-by-case basis.

Procedure

Prior to installing package-name 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.

1. Open a terminal.

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

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

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

Start Menu → Xfce Terminal

2. In Whonix-Workstation (whonix-workstation-17 Qubes-Whonix^™) konsole, add Debian stable codename bookworm to the apt-conf default-release.

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

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

sudo su -c "echo -e 'deb https://deb.debian.net/debian 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 update

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

sudo apt install package-name/sid

6. Undo.

On occasion it is necessary to undo this configuration, for example when upgrading from Debian bookworm to trixie. 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

Install from Custom APT Repository

Adding custom APT repositories is mostly unspecific to Whonix. Should be the same or at least very similar to the process on Debian because Whonix is based on Debian. Therefore the user should utilize the Self Support First Policy.

To add custom APT repositories, there are few different cases (non-exhaustive list):

• A) Only the provider of the custom APT repository provides instructions how to add the custom APT repository to the system.
• B) Sparse or no instructions on how to add the custom APT repository to the system.
• C) Documentation exists but is for a different Linux distribution such as Ubuntu and cannot be trivially translated to Debian based Linux distributions such as Whonix.
• D) For some custom APT repositories, there are detailed instructions on how to add the custom repository in the Whonix documentation. Examples for documented third-party repositories include: Signal messenger, Session messenger, The Tor Project.

No generic documentation can be provided to cover any custom APT repository since it is dependent on the specific custom repository. In other words, it varies depending on the custom repository. The steps required per custom repository are similar but not the very same.

The generic basic skills required to add a custom repository where documentation is insufficient are:

1. Acquire an APT signing key signing key.
2. Open file with root rights.
3. Copy a file with root rights.
4. Adding an APT signing key to APT keyring.
5. Adding an APT repository file to the /etc/apt/sources.list.d folder.

The generic advanced skills required for better security that are required are:

1. Securely download an APT signing key.
2. View and verify an OpenPGP key fingerprint for better security.
3. Open file with root rights.
4. Copy a file with root rights.
5. Adding a signing key to the /usr/share/keyrings folder
6. Adding an APT repository file to the /etc/apt/sources.list.d folder.
7. Configuring an APT repository to use a single specific APT signing key file only using signed-by. (forum discussion: APT repository signing keys per APT sources.list - signed-by)

Package Reinstallation

As per the free support principle, package re-installation utilizes normal Debian processes.

The example below shows how the keepassxc package would be reinstalled. It is possible to substitute keepassxc 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 re-installation would be very difficult and is currently unsupported.

Even in the keepassxc package example, dependency complications emerge. In the example below the kicksecure-qubes-gui package also depends on keepassxc.

1. Update the package lists and upgrade.

See Updates for instructions.

2. Purge the package you want to reinstall.

sudo apt purge keepassxc

The output will show something like the following.

sudo apt purge keepassxc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libqrencode4 libqt5concurrent5 libykpers-1-1 libyubikey-udev libyubikey0 libzxcvbn0
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  keepassxc* kicksecure-desktop-applications-recommended* kicksecure-qubes-gui*
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
After this operation, 19.1 MB disk space will be freed.
Do you want to continue? [Y/n]

The packages kicksecure-qubes-gui has been inadvertently uninstalled due to technical limitations. These packages are reinstalled at a later step.

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

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

rm -r ~/.keepassxc

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

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

sudo apt install --no-install-recommends keepassxc kicksecure-qubes-gui

Related to: Whonix Debian Packages.

Install Software in an App Qube

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 App Qubes, 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.

Advantages

This software installation method means a single VM assumes many of the positive characteristics found in both App Qubes and Standalones.

• Centralized Updates: App Qubes are based on a Template. This means the App Qube's root filesystem is based on the corresponding template's root filesystem. Any updates to the Template will be reflected in the App Qube's root filesystem upon restart.
• Minimal Disk Usage: App Qubes require much less disk space than Standalones, since the App Qube's root filesystem is based on the corresponding template. The App Qube 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 and Wire store user data in the /home folder. Since the custom script installs the software seamlessly with little or no user interaction, the App Qube has "quasi-full persistence", not unlike a Standalone's full persistence.

App Qube Preparation

1. Create an App Qube based on whonix-workstation-17.

2. Pre-install any necessary dependencies.

Dependencies are available from packages.debian.org and can be pre-installed in the Template to speed up the repetitive software installation process. This means only packages or software missing from packages.debian.org will be repeatedly installed in the App Qube.

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 update, after the repository and signing key are imported
• finally running apt install to install the relevant software package(s)

App Qube Use

The App Qube's root filesystem does not provide a strong non-persistent security feature. The persistence of the /home, /rw, and /usr/local filesystem means malware can be specifically written to target Qubes-based App Qubes, inserting hooks inside these directory's files.

Once user preparation is complete and the App Qube has started, it will automatically start the script to begin installing software. When the process finishes, the App Qube can be used like any other. However when the App Qube 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

Using selective bind-dirs 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

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] Type=Application Exec=/path/to/program Name=program-name Categories=Other

4. Save the file.

5. Done.

The procedure is now complete.

6. Start using the launcher.

The launcher can be found here:

Start Menu → Other → program-name

snap

General forum discussion about snap: Snap Store / snaps / snapd / snapcraft.io - a new software source?

Qubes-Whonix issues:

• Efforts to persistently install snap apps in Qubes-Whonix via bind-dirs or with snap proxy settings have been unsuccessful. This means it must be installed in an App Qube on every occasion it is required. Efforts to improve this situation are most welcome, see: Wickr Me vs Qubes-Whonix Persistence and snap totally unusable on Qubes-Whonix.
• Qubes Templates are non-networked by default, which means snap does not run inside whonix-workstation-17 Template. It is likely snap is similarly affected in other Qubes' Templates like the Debian Template. As per Self Support First Policy it is recommended to test snap functionality in a non-Whonix based Template before attempting the same procedure inside Whonix.

Apparently software in snap store is not well vetted for being non-malicious. Uploader "bitcoin1btc" uploaded an unofficial, reportedly malware (money stealing) application Ledger Live: Crypto & NFT App. Unclickable link: https://snapcraft.io/ledgerlive - Scam!

Note: For avoidance of doubt, while Ledger has been criticized for its Ledger Recovery service among other things, this is not Ledger's fault. There is no way for Ledger to prevent its software to be uploaded by malicious third-parties to arbitrary software stores.

Even days after this has been reported, snap store did not take action to remove the malware from their store.

In conclusion, snap store has bad software verification practices as well as a broken incident response procedure.

Flatpak

Introduction

Flatpak is:

...a utility for software deployment and package management for Linux. It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system. ...

Applications using Flatpak need permissions to have access to resources such as Bluetooth, sound (with PulseAudio), network, and files. These permissions are defined by the maintainer of the Flatpak and can be added or removed by users on their system.

Another key feature of Flatpak is that it allows application developers to directly provide updates to users without going through distributions, and without having to package and test the application separately for each distribution.

There are several advantages of utilizing Flatpak:

• Packages are easily added via Flathub, which is a repository located at flathub.org; for a Whonix example, see here.
• Numerous Linux distributions are either supported out-of-the-box or after the flatpak package is installed; Debian is a supported platform (which Whonix is based upon).
• Desktop applications are sandboxed and have limited access to the host environment.
• Flatpak bundles are a single-file format which contains the application or runtime.
• Any Flatpak breakage will not lead to destabilization of the host OS.
• Elevated privileges (root) are not required to install Flatpak packages.
• Only changed files are downloaded for updates.
• Libraries and files used by multiple applications are de-duplicated to save space.

For further information, refer to the Flatpak FAQ and Flatpak documentation.

Flathub Package Sources Security

Flathub, a central repository for Flatpak applications, hosts Flatpaks from various sources:

• A) Official Flatpaks: These are packaged directly by the original developers of the application. Also called verified apps or sometimes publisher verification.
• B) Unofficial Flatpaks: These packages are created by third-party developers.

Official Flatpaks are clearly identified by a blue verified checkmark, but the absence of any indicator on unofficial Flatpaks creates a risk of confusion and security concerns. It is essential to have a distinct visual signal, such as a red 'unverified' mark, on these unofficial Flatpaks. This is crucial for ensuring that users are fully aware of the non-verified nature of these applications, thereby significantly reducing the likelihood of downloading potentially harmful software. The current lack of differentiation is a clear Flathub failure that compromises user safety, as it could lead users to mistakenly trust and download malware from unverified sources.

Figure: Firefox Flatpak showing the blue verified checkmark

A security concern was identified with the Mullvad Browser Flatpak, as reported in this issue. Although it appeared as an official Mullvad Browser Flatpak, it was, in fact, unofficial and impersonating the official version. The appearance of this Flatpak can be viewed in the archived webpage.

Mullvad Browser
by Mullvad

This issue was partially addressed by the third-party Flatpak packager, who was non-malicious. They added the following notice to clarify the situation:

NOTE: This wrapper is not verified by, affiliated with, or supported by Mullvad VPN AB.

The Monero Project requested a verified checkmark for the Monero GUI Flatpak. However at time of writing in January 2023, this is being delayed by Flathub since August 2023 by Flathub.

Flathub acknowledged the need for improvement publisher verification, as discussed in this forum thread. They initiated beta.flathub.org with the intention of enhancing verification, but this now redirects to flathub.org, and the feature providing detailed verification information is not yet implemented on the Flathub website. The current status of this feature, whether it is deprecated or still in planning, is unclear as the full forum thread has not been reviewed, nor has further research been conducted.

In the next version of Kicksecure, there are plans to mitigate this issue by enabling the Flathub repository by default. See Kicksecure Flathub Repository Default Settings.

Depending on the application, Flatpaks are either:

• A) Built from source code, or
• B) Downloaded in binary (non-source) format from the original developers.

Flathub's build process of downloading binaries poses certain risks. Since builds are automated, it is unlikely and not enforced that the packager verifies that the source code is complete, can be compiled, and is free of binary blobs, Embedded Code Copies of libraries, other software, or non-freedom software. In contrast, Debian policy strictly prohibits embedded code copies in all software from the Debian repository (packages.debian.org). Moreover, Debian build servers do not have external network access, ensuring that software can be built while all build dependencies are sourced exclusively from the Debian repository, avoiding reliance on any remote sources.

Flatpak or the Flathub.org web interface currently does not show if Flatpaks are built from source code or downloaded as binary from the original developers. Flathub feature request: Indicate on flathub.org Whether a Flatpak is Built from Source or Binary During Build Process on Flathub

Table: Comparison of Various Flatpak Applications

Name of Flatpak	Upstream	Subline	Risk of User Confusion	Flatpak Packager	Manifest File	Official/Non-Official	License Type	Method of Build
Visual Studio Code	Microsoft	by Microsoft Corporation	high	Third-party	link	Non-Official	Non-Freedom	Binary
VSCodium	VSCodium	by Peter Squicciarini	medium (missing unverified mark)	Third-party	link	Non-Official	Freedom	Binary
Firefox	Mozilla	by Mozilla	none (verified mark)	Mozilla	link	Official	Freedom	Binary

For the source of this information, please press on expand on the right.

• This can be seen by looking on Flathub.org for the fields developer and publisher.
• By looking at the manifest files, it is easy to see.
  • Visual Studio Code: url: https://packages.microsoft.com/repos/code/pool/main/c/code/code_1.85.1-1702462158_amd64.deb
  • VSCodium: sources: - type: file url: https://github.com/VSCodium/vscodium/releases/download/1.85.1.23348/codium_1.85.1.23348_amd64.deb sha256: 28cdc4df80f8cfdb69532cae8b1b19515ce24290217c1fa97b1946ccf3e1f25a
  • Firefox: # Download en-US linux64 binary $CURL -o "${WORKSPACE}/firefox.tar.bz2" \ "${CANDIDATES_DIR}/${VERSION}-candidates/build${BUILD_NUMBER}/linux-x86_64/en-US/firefox-${VERSION}.tar.bz2"

See also: The security risks of Flathub

Online discussions:

• https://www.reddit.com/r/linuxquestions/comments/1139nri/is_flathub_safe/

Flatpak Package Manager Security

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

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

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, it is fetched over TLS. Adversaries capable of breaking TLS face an obstacle when dealing with torified connections (like those in torsocks flatpak -- 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 Tor → Target specific user(s) → Break TLS → Mount an indefinite freeze attack → Exploit 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:

• This is the associated org.chromium.Chromium flathub website page.
• The additional information section lists:
  • Updated: October 5, 2021
  • Version: 94.0.4606.71

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.

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). 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:

• flathub as a source of software.

Flatpak Sandbox Security

Flatpak's sandbox is imperfect. Despite Flatpak sandbox issues, it is safe to use in the software installation context. By comparison, Debian's default package manager APT and other Linux package managers do not attempt to sandbox applications.

Flatpak is a victim of imperfect marketing. Since the Flatpak sandbox is a built-in feature, any reported security issues reflect negatively on Flatpak's reputation. Frequently, non-technical users are unable to properly contextualize or assess its impact through threat modeling. Building a "perfect" sandbox is a much harder task - containing arbitrary, ever-changing applications running on an ever-changing operating system - than creating a package manager. The latter is essentially a file delivery mechanism and is therefore comparatively simpler to develop.

Flatpak's sandboxing abilities are irrelevant so long as the sandboxing is not worse than software that is manually installed.

Flatpak Breaking the Native Sandbox of Applications

Flatpak's sandbox, which is mandatory and cannot be disabled, can break application’s native sandboxing. For example, in case of Chromium Flatpak, adjustments were required.

The Chromium Flatpak has patches on it to utilize Flatpak's support for nested sandboxing.https://github.com/flatpak/flatpak/issues/4032

Flatpak's own sandboxing capabilities interfere with other sandboxing initiatives like Sandboxed Application Launcher and Firejail:

See also the discussion Does Flatpak weaken Chromium/Firefox’s sandbox?

Is Flatpak compatible with other desktop isolation frameworks?

In general, unprivileged container systems can’t stack, because anything running inside the sandbox does not have the necessary privileges to set up a sandbox, nor does it have the ability to raise its privileges in any way. For instance, Firejail can never work inside Flatpak, because it is setuid. That being said, using multiple sandboxing frameworks at once does not really make anything more secure, so there is little point in trying to nest things like that.

In the case of Sandboxed Application Launcher, it is not used much at the time of writing. However, that is not a reason against using it. Flatpak's own sandboxing and Sandboxed Application Launcher can be co-installed without issues, but the latter will be unable to sandbox applications installed through Flatpak.

Ruarí (Vivaldi Browser Team) also confirmed this.

Flatpak Criticism

Flathub Promoting non-freedom Software

Oh, also, even if I have that, flathub lists proprietary apps right next to free software apps without any distinction. That is very bad. The search and listing functionality do not allow me to find only free software apps. l read the little license field, and if you are a new user, how are you going to know that a little unexplained license acronym like "MIT" or "GPL-3.0" means it is free software? It is sending the message, the license is a small unimportant detail, things that are way more important are: it's functionality category, the editor's choice, it's "popularity", because you can find apps through that, but not if it has a free license. Also, the license information is much worse. In debian based distros, I can easily see the license of every dependency. There is more complete licensing info in /usr/share/doc/PACKAGE/copyright. And I know that someone has put some time and effort into checking them.LWN Comment

Flathub could mitigate this by now showing non-freedom software by default and only for users who opt-in. Such functionality is however not planned according to the knowledge of the author.

Higher Disk Space Requirements

As explained here, flatpak requires more disk space.

Qubes OS Specific

At the time of writing, applications installed using Flatpak do not present in the Qubes start menu.
Workaround: navigate to Qube settings → applications tab → press "Refresh Applications".

Flatpak - system-wide versus per-user

Flatpak can either be used system-wide or per-user.

• A) system-wide: without the --user option.
  • example: flatpak install flathub org.chromium.Chromium
• B) per-user: when using the --user option.
  • example: flatpak --user install flathub org.chromium.Chromium

Enable Flathub Repository

prerequisite knowledge: Flatpak - system-wide versus per-user

The Flathub repository by default in Whonix:

• A) system-wide: enabled.
• B) per-user: not enabled.

If the user wishes to see the instructions on how to enable the Flathub repository, please press on Learn More on the right side.

1. Notice.

Optional: Digital signature verification.

• Digital signatures are a tool enhancing download security. They are commonly used across the internet and nothing special to worry about.
• Optional, not required: Digital signatures are optional and not mandatory for using Whonix, but an extra security measure for advanced users. If you've never used them before, it might be overwhelming to look into them at this stage. Just ignore them for now.
• Learn more: Curious? If you are interested in becoming more familiar with advanced computer security concepts, you can learn more about digital signatures here digital software signatures.

The following flatpak remote-add command in step 2 is not the most secure way to do this. However, it is the most popular method and is also recommended in the official instructions by upstream, Flathub. As of 18 January 2024, the author of this warning has not found any significant concerns about this method anywhere else on the internet.

A strong understanding of the content on the Verifying Software Signatures wiki page is essential to comprehend this issue.

The concern arises because the command uses TOFO (Trust on First Use), which is not the most secure approach. Employing this method reduces the System Security Level from Always use software signatures verification to Always use TLS. This change occurs because the Flatpak repository definition file, downloaded over TLS, includes an OpenPGP (gpg) signing key, which is not authenticated by any means stronger than TLS. This concern relates to Checking Digital Fingerprints of Signing Keys.

To mitigate this security issue, users should avoid using any flatpak remote-add command. Instead, they should add a configuration snippet directly to the /etc/flatpak/remotes.d directory. For instance, creating a file like /etc/flatpak/remotes.d/flathub.flatpakrepo would be advisable. This configuration file, or the content of its GPGKey= keyword, should be obtained from sources authenticated by means stronger than TLS. This process is currently undocumented.

Flatpak upstream bug report: flatpak remote-add TOFU and TLS security issue / use stronger authentication than TLS

This issue is unspecific to Whonix.

2. Select your platform.

A : Non-Qubes-Whonix^™

===

Whonix-Workstation

(Not required. Enabled by default.)

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

B : Qubes-Whonix^™ Template

===

Qubes-Whonix Template (whonix-workstation-17)

(Not required. Enabled by default.)

http_proxy=http://127.0.0.1:8082 https_proxy=$http_proxy flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

C : Qubes-Whonix App Qube

Qubes-Whonix App Qube (anon-whonix)

Required. Not enabled by default.

flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

3. Done.

The process of enabling the Flathub repository has been completed.

Kicksecure Flathub Repository Default Settings

Kicksecure mitigates the issues described in chapter Flathub Package Sources Security related to unverified applications and non-freedom software by using Flatpak's subset option with the verified_floss parameter, which means that only Flatpaks can be installed that are both verified apps and floss (Freedom Software).

This means by default it will not be possible to install unverified or non-freedom software Flatpaks from Flathub. This is to avoid the user accidentally installing Flatpaks from one of these two categories. Unverified Flatpaks are disabled by default for better security. Non-freedom Flatpaks are disabled to Avoid Non-Freedom Software.

This is not a user freedom restriction. In Kicksecure, there are No Intentional User Freedom Restrictions. This setting can be easily changed. See chapter Change Flathub Settings.

Change Flathub Settings

Flathub offers support for subsets, which is relevant to the discussion in Flathub Package Sources Security. The recommended setting is verified_floss. However, if you are confident in your understanding of these settings, you are free to choose different options as per your requirements.

For instance, as of this writing, Monero could not be installed due to its Flatpak not having received the verified badge from Flathub. This situation is a result of delays in verification by Flathub, as detailed in Flathub's issue tracking. If a user has independently verified that an application deemed unverified is from a reputable source, they may choose to modify their settings to allow the installation of unverified Flatpaks. In the case of Monero, if the user already has confidence in the Monero developers, it might be reasonable to permit the installation of the unverified Monero Flatpak, especially considering it has been developed by the Monero team and is in the process of becoming a verified Flatpak.

It's important to note that once you enable the installation of unverified or non-freedom software Flatpaks, extra caution is required to avoid inadvertently installing other unverified or non-freedom software Flatpaks. This is due to the lack of an option to permit unverified Flatpaks on a per-Flatpak basis. Instead, there's only a global Flatpak setting, which affects all instances of the Flatpak installation command.

Table: flatpak subsets - Security Viewpoint

Option / Comment	No Unverified Publishers Allowed	No Non-Freedom Software Allowed	Command
Flathub default.	No	No	sudo flatpak remote-modify --subset= flathub
verified	Yes	No	sudo flatpak remote-modify --subset=verified flathub
floss	No	Yes	sudo flatpak remote-modify --subset=floss flathub
verified_floss Recommended.	Yes	Yes	sudo flatpak remote-modify --subset=verified_floss flathub

The following table expresses the very same as above, just from a different viewpoint.

Table: flatpak subsets - Functionality Viewpoint

Option	Unverified Publishers Allowed	Non-Freedom Software Allowed	Command
	yes	yes	sudo flatpak remote-modify --subset= flathub
verified	no	yes	sudo flatpak remote-modify --subset=verified flathub
floss	yes	no	sudo flatpak remote-modify --subset=floss flathub
verified_floss	no	no	sudo flatpak remote-modify --subset=verified_floss flathub

Recommendations:

• Installation of unverified Flatpaks is discouraged for better security.
• Installation of non-freedom software is discouraged as per Avoid Non-Freedom Software.

Install from Flatpak

This is an example.

Note: Replace the Flatpak application ID org.chromium.Chromium with the actual Flatpak application ID to install such as for example org.mozilla.firefox.

Install org.chromium.Chromium via flatpak.

1. Add a Flatpak repository.

Select your platform.

A : Non-Qubes-Whonix

===

Non-Qubes-Whonix

Already enabled by default. (system-wide). No additional steps needed to enable the Flathub repository.

B : Qubes-Whonix Template

===

Qubes-Whonix Template (whonix-workstation-17)

Already enabled by default. (system-wide). No additional steps needed to enable the Flathub repository.

C : Qubes-Whonix App Qube

Qubes-Whonix App Qube (anon-whonix)

The user needs to Enable the Flathub Repository. Must be enabled per-user.

2. Install the flatpak org.chromium.Chromium package.

A : Non-Qubes-Whonix

===

Non-Qubes-Whonix

flatpak install flathub org.chromium.Chromium

B : Qubes-Whonix Template

===

Qubes-Whonix Template (whonix-workstation-17)

Note: Advanced users that uninstalled the qubes-core-agent-passwordless-sudo package should see forum thread Warning: Flatpak system operation Deploy not allowed for user.

http_proxy=http://127.0.0.1:8082 https_proxy=$http_proxy flatpak install flathub org.chromium.Chromium

C : Qubes-Whonix App Qube

Qubes-Whonix App Qube (anon-whonix)

flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

flatpak --user install flathub org.chromium.Chromium

3. Done.

The procedure of installing org.chromium.Chromium is complete.

4. Upgrades notice.

Note: this procedure will not keep the software up-to-date. How to update installation installed by flatpak is also documented on the Operating System Software and Updates wiki page.

Flatpak Troubleshooting

Flatpak error: Nothing matches

If you encounter an error message similar to the one below...

Looking for matches…
error: Nothing matches org.getmonero.Monero in remote flathub
zsh: exit 1     flatpak install flathub org.getmonero.Monero

...it may be due to the software being a unverified application and/or not being non-freedom software. This issue can arise because of the hardened Kicksecure Flathub Repository Default Settings, which are designed to mitigate some security issues outlined in the section Flathub Package Sources Security.

To override these restrictions and proceed with installation, refer to the instructions in the section Change Flathub Settings.

Installers

curl bash pipe's are to be avoided for security reasons. See also curl bash pipe - Security Discussion.

Examples.

NOTE: Do not run the following command! These are only an illustrative examples.

curl https://www.example.com/installer | bash

bash <(curl -sL s5n.sh) && . ~/.bashrc

bash <(wget -qO - s5n.sh) && . ~/.bashrc

Best Practices

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 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, unless special circumstances exist. 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.
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. APT is a secure package manager which passes the TUF threat model, since it features metadata verification and expiration detection.
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 provides a strong rationale for using the stable repository; see footnote. 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.

Security Advice

General Advice

Whonix users are free to install their favorite software packages, but should be aware that additional software increases the attack surface of the platform.

APT Meta-data

When updating with apt, information will leak about which software packages and versions have been installed, unless Tor onion repositories have been configured.

For repositories that come enabled by default with Whonix, this meta-data cannot be directly linked to any other activity like web browsing, because the apt-transport-tor forces it to pass through its own Tor circuit.

For user custom added repositories, the user should consider adding the onion version of that repository if available or use apt-transport-tor with the tor+ syntax in the apt sources file. Undocumented. The user could refer to upstream apt-transport-tor documentation.

Recommendations

For greater security when updating:

• Follow the guidelines below.
• Be especially careful when adding custom repositories, particularly Personal Package Archives (PPAs). Compared to main distribution repositories, solo developers are more susceptible to influence and theoretically might have malicious intent.

How-to: Install or Update with Utmost Caution

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.
3. Update using apt 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.

Specialized topics

--no-install-recommends

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, 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 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 are also available.

If a package is installed using apt --no-install-recommends install package-name, then re-running apt 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 (Recommends:), 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 https://www.debian.org/distrib/packages.

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

Table: --no-install-recommends Impacts

Question	Answer
Why does Whonix documentation often suggest --no-install-recommends?	Whonix documentation uses --no-install-recommends whenever appropriate. It has been specifically crafted by developers with the goal of installing all required packages.
Can using --no-install-recommends lead to security issues?	No.
Can using --no-install-recommends lead to missing or broken functionalities?	Yes. For example, mmdebstrap uses Recommends: and Suggests: for various optional dependencies providing various functionality.
Can omitting --no-install-recommends lead to security issues?	In corner cases, yes. For example consider a host operating system without a Host Firewall. By omitting --no-install-recommends -- which results 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 to the apt installation command. Otherwise, there might be corner cases of missing optional dependencies or limited functionality. In general, whether users should use --no-install-recommends for package installation is unspecific to Whonix and should be resolved as per Self Support First Policy.
Should Whonix set the default to --no-install-recommends?	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 Self Support First Policy 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 Self Support First Policy. 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 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.
How to install Recommends: after previously using --no-install-recommends to install a package?	Scenario: You previously installed a package using the command: apt install --no-install-recommends diffoscope User Story: - Initially, the absence of Recommends: was intentional and desired. - Later, the realization occurs that the missing Recommends: are needed after all. Attempts: 1. Running: apt install diffoscope Expected Result Recommends: are installed now. Actual Result: The Recommends: are not installed. 2. Running: sudo apt satisfy diffoscope or even: sudo apt install --install-recommends diffoscope Outcome: The Recommends: still do not get installed. Workaround: The only effective method discovered so far is to remove the package first: sudo apt remove diffoscope Then reinstall it with the --install-recommends flag: sudo apt install --install-recommends diffoscope Related Information: Refer to the following Debian APT bug report/feature request: apt-get --install-recommends --reinstall install x should install recommends for already installed package

Default APT Sources

APT sources configuration,

• /etc/apt/sources.list file and
• /etc/apt/sources.list.d folder

work same as on Debian. This is unspecific to Whonix. The only Whonix specific difference is that file /etc/apt/sources.list exists but is empty by default. Debian APT sources reside in file /etc/apt/sources.list.d/debian.list, which is provided by the anon-apt-sources-list package.

Foreign Sources

For most use cases the extensive software range available from the official Debian repositories should be sufficient. A selection of nearly 60,000 programs 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.

Risks

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

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 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.

Dependency Hell

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.

Mitigation

To reduce security risks and eliminate the risk of making the workstation unusable, utilize Multiple Whonix.

Qubes-Whonix users: For installation inside Qubes templates, the risk can only be minimized by using Multiple Qubes-Whonix Templates.

Installation Source - Upstream Original Developers versus Repository

Installation from Upstream Original Developers versus Repository? Which one is more secure?

That depends on the user's knowledge. If the user has a strong understanding of computer security in general, specifically fully understands the threat model behind digital software verification, then downloading software from original upstream developers is probably safer (because that removes one intermediary) than installing from other sources such as flatpak. However, this is a very big "IF."

related knowledge:

• Verifying Software Signatures
• Software Signature Verification Usability Issues and Proposed Solutions
• Mental Model
• Social Engineering

GUI Applications with Root Rights

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

Footnotes

Whonix The most watertight privacy operating system in the world.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Whonix is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Whonix we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2025 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

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 13 year success story and maybe DONATE!