Placing Trust in Whonix ™

From Whonix


Trust is a very problematic issue. This is the essence of why security is difficult in every field, including general computing and Internet communication. A skeptical user might ask themselves the following questions before relying upon Whonix ™ for sensitive activities on a daily basis:

  • Can Whonix ™ and its developers be trusted?
  • Are backdoors present in Whonix ™ that can take control over a computer or exfiltrate data?
  • Does Whonix ™ generate compromised encryption keys to enable government spying?
  • How trustworthy and sincere are the stated anonymity goals of the Whonix ™ project?

Opinions will vary widely, but the reasoning process used to reach the conclusion should be closely examined. It is important that both trust and distrust are based on facts, and not gut feelings, instincts, paranoid conceptions, unfounded hearsay or the words of others.

It is unsurprising that the Whonix ™ project and other anonymity platforms / tools claim to be honest, but written assurances are worthless. For an informed decision, it is worth looking at the bigger Whonix ™ picture: core components, affiliations, project track record, and how reasonable trust might be established.

Free Software and Public Scrutiny[edit]

Whonix ™ and other free software makes it possible to check the source code to determine how a software distribution functions and what it consists of. Suitably skilled individuals can thoroughly audit the code to search for the presence of any malicious code, like a backdoor. In addition, software can be manually built from source code and the result compared against any versions that are pre-built and already being distributed, like the Whonix ™ ova images that can be downloaded from This comparison can determine whether any malicious changes were made, or if the distributed version was actually built with the source code.

Naturally most people do not have the requisite knowledge, skills or time to properly audit software. However, the public scrutiny of popular, open source software implies a certain degree of trustworthiness. The axiom attributed to Linus Torvalds [1] -- "Given enough eyeballs, all bugs are shallow" -- is a reasonable assumption in user communities that are large, vibrant, and focused on fixing security vulnerabilities quickly. [2] The free software community has a strong tradition of publicly reporting and resolving serious issues, and a large pool of developers and beta testers can help to identify and remedy problems. [3]

Trusting Debian GNU/Linux[edit]

Nearly all the software shipped in Whonix ™ comes from the Debian GNU/Linux distribution. Debian's packages are heavily scrutinized as it is one of the largest Linux distributions at present. Debian is also one of the most popular distributions for derivative platforms; Ubuntu Linux is a Debian derivative, and the same applies to all Ubuntu derivatives such as Linux Mint.

The sheer number using Debian's software packages and the large developer pool inspecting software integrity are significant factors in Debian's favor. Debian regularly identifies and patches serious security issues like the infamous SSH PRNG vulnerability [4], but backdoors or other purposeful security holes have never been discovered to date. Debian's focus on security is further evidenced by their Security Audit team which constantly searches for new or unfixed security issues. [5]

Trusting Tor[edit]

Whonix ™ anonymity is based on Tor, which is developed by The Tor Project. Tor is a mature anonymity network with a substantial user base, and it has developed a solid reputation after more than 15 years of development. Tor's distributed trust model makes it difficult for any single entity to capture a user's traffic and identify them on a consistent basis.

Tor and its general development are subject to heavy public scrutiny by academics, security professionals and a host of developers. [6] For example, there is a body of Tor research related to potential attack vectors on onion routing and the adequacy of current defenses, and the source code has undergone several external audits. Like any software project, numerous security issues have been identified and resolved over the years, but a purposeful backdoor has never been discovered. [7] Theories about deliberate backdoors in Tor are considered highly speculative and lacking any credible basis.

Trusting Whonix ™[edit]

In one sense, Whonix ™ is the simple union of Debian and Tor and a mechanism to glue them together. If a user already trusts Debian and The Tor Project, then a method for assessing Whonix ™ trustworthiness is also necessary.

The Whonix ™ project was founded on 11 January, 2012. It previously existed under different project names, including TorBOX and aos. As mentioned earlier, Whonix ™ is free software which makes the source code available for inspection. In the main, Whonix ™ is comprised of specifications for which Debian software packages should be installed and their appropriate configuration. Unfortunately, Whonix ™ does not receive the kind of attention that is dedicated to Debian or Tor, and a formal, external audit has not yet taken place.

With a relatively small development team and estimated user base, the "many eyeballs" theory may work against Whonix ™ at present. However, the source code is comparably small and devoid of complexities, meaning the project is in relatively good shape compared to many other similar projects. Interested readers can learn more about the Whonix ™ specification and design here. [8]

With these factors in mind, the reader can now make an informed decision about the trustworthiness of Whonix ™.

Whonix ™ Warrant Canary[edit]

Info The first Whonix ™ warrant canary went live on 13 March, 2019. [9]

The Whonix ™ warrant canary is intended to provide a means of communication to users in the event Whonix ™ is served with a secret subpoena, despite legal prohibitions on revealing its existence. For any canary in force, once the signature of the canary file is verified with OpenPGP, this confirms that no warrants have been served on the Whonix ™ project.

Note: the canary date of issue is represented by the gpg signature date. A new canary should be released within 4 weeks. [10]

The canary and signature are available here:

As a backup, the canary and signature are also available on github: [11]

Readers are reminded this canary scheme is not infallible. The canary declaration is provided without any guarantee or warranty, and it is not legally binding upon any parties in any form. The signer should never be held legally responsible for any statements made in the canary.

Trusting Downloaded Images[edit]

Users should not blindly trust the Whonix ™ project or its developers. Logically it is unwise to trust unknown persons, especially on the Internet. On that basis, trust in Whonix ™ founder Patrick Schleizer should not rely on his public persona or the appearance of the Whonix ™ project alone. Whonix ™ may be or could become a high profile target, and it is risky to assume that Schleizer's build machine would remain clean under those circumstances.

Binary images can be trusted to some extent if a user verifies that they received exactly the same code as thousands of other users, and no one has found or publicly reported any serious security issues. This requires verification of the Whonix-Workstation ™ and Whonix-Gateway ™ images using the available OpenPGP signatures. [12] All binary releases and source code tags for releases are OpenPGP-signed by lead Whonix ™ developer Patrick Schleizer.

In order of increasing security, the Whonix ™ images can be:

  1. Downloaded via TLS provides some trust and integrity of the hash file, but it is still advisable to check the site's certificate and perform manual OpenPGP verification.
  2. Downloaded over the Whonix ™ v3 onion address with Tor Browser before OpenPGP verification. Onion addresses provide a higher standard of authentication than clearnet addresses.
  3. Built from source since it is a relatively easy procedure. [13]

Trusting the Whonix ™ Website[edit]

As noted in the FAQ chapter addressing Privacy on the Whonix ™ Website, three separate web-based platforms are currently in use:

  1. Discourse for the Whonix ™ forums.
  2. MediaWiki for online documentation.
  3. Phabricator (mostly) for the Whonix ™ project's issue/bug tracker.

The problem is these web applications (web apps) are developed independently from Whonix ™. This means Whonix ™ developers have little to no control over the course these projects take. Since privacy and security issues often take a back seat to "enhanced features", websites relying on these or similar web apps can at best only provide privacy by policy, which is equivalent to a promise.

It is infeasible from a monetary, time and manpower perspective to address perceived shortcomings in these web apps. This means the Whonix ™ community should not place undue trust in the live version of this site on the Internet, due to the potential for interference.

Distrusting Infrastructure[edit]

In an identical fashion to the Qubes project, Whonix ™ has adopted the principle that all infrastructure should be explicitly distrusted. Infrastructure in this context refers to " providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc." [14]

Third parties who operate infrastructure are "known unknowns" and potentially hostile. It is safer to voluntarily place trust in a few select entities, such as the maintainers of Whonix ™ packages, the holder(s) of Whonix ™ signing keys and so on. By sufficiently securing endpoints, it is unnecessary to try and improve the trustworthiness of those operating the "mid-points". This also provides two benefits: Whonix ™ forgoes the need to invest valuable resources on the problem, and no illusory security expectations are raised in the Whonix ™ community. [14]


Fingerprint Trust[edit]

Most users retrieve OpenPGP fingerprints directly from a website and then download an associated key from a key server. The problem with this method is that TLS is fallible and the connection could be insecure or broken. Greater security necessitates a key signing party, whereby a direct and trusted path of communication can be confirmed by all attendees. If this step is not followed, OpenPGP is only secure as TLS.

It is often impossible to meet this condition of meeting in person. To mitigate the risk, any OpenPGP fingerprint should be cross-referenced on multiple "secure" (https://) sites. An additional fail-safe is to use an alternative authentication system, for example comparing the Tor signing keys on both the clearnet and onion domains: and http://expyuzz4wqqyqhjn.onion/docs/signing-keys.html

Onion services offer strong authentication via multiple layers of encryption. This does not prohibit an advanced adversary from trying to impersonate an onion service, but together with multiple fingerprint sources, it becomes increasingly difficult and improbable that a single entity could impersonate them all.

Whonix ™ Binaries and Git Tags[edit]

All Whonix ™ binaries are OpenPGP-signed by Whonix ™ developer Patrick Schleizer. [15] The source code is directly available on github over TLS, and it can be cloned using git over https://. Git tags for each release are also OpenPGP-signed by Whonix ™ developer Patrick Schleizer. Users can also request signed git development tags from the same developer.

Even if Whonix ™ developers are distrusted, verifying binary downloads or git tags with OpenPGP is still useful. For example in order to audit Whonix ™, it is important to verify the download came from Whonix ™ developers and that it was not tampered with by third parties. This is a realistic threat, as these recent examples show:

The OpenPGP key also ensures that if the Whonix ™ infrastructure is ever compromised by a powerful adversary (such as a domain takeover), the original Whonix ™ developers can at least prove they owned the infrastructure.

Whonix ™ Developer OpenPGP Guidelines[edit]

All long-term Whonix ™ developers are encouraged to:

  • Create a 4096/4096 RSA/RSA OpenPGP key.
  • Retrieve the latest gpg.conf which comes with Whonix-Workstation ™ for stronger hashes, no-emit-version, and other improved settings.
  • Store the private key inside an encrypted file.
  • Make a backup of that encrypted file.
  • Remember the password and regularly test one's memory of it.
  • Upload the encrypted file to a (free) online cloud-based host to protect against theft, fire, natural events and so on.

From the beginning of the Whonix ™ project, greater trust has been placed in developers who publish their OpenPGP public key earlier on, since this reduces the probability of an evil developer attack.

Verifiable Builds[edit]

Verifiable .ova Releases[edit]

verifiable builds warning icon Warning:

Deprecated. A dedicated maintainer is required.

Whonix previously had a feature which allows the community to check that Whonix .ova [16] releases are verifiably created from the project's own source code - verifiable builds. [17] This only proves that the person and machine [18] building Whonix have not added anything malicious, such as a backdoor. [19] It does not prove there are no backdoors present in Debian. This is not possible, because neither Debian [20] nor any other operating system provides deterministic builds yet. [21]

This feature does not attempt to prove there are not any vulnerabilities present [22] in Whonix or Debian. Fatal outcomes are still possible via a remotely exploitable [23] bug in Whonix or Debian, a flaw in Whonix's firewall which leaks traffic, or code phoning home [24] the contents of the HDD/SSD. Community effort is a precondition to improved security with this feature, particularly auditing of Whonix and Debian source code to check for possible backdoors and vulnerabilities.

In summary, this feature is useful and potentially improves security, but it is not a magical solution for all computer security and trust issues. The following table helps to explain what this feature can achieve.

Table: Verifiable Builds Comparison

Whonix ™ Tails Tor Browser Qubes OS TorVM corridor
Deterministic builds [25] No No (planned) [26] Yes [27] No Not applicable [28]
Based on a deterministically built [25] operating system No [29] No [29] Not applicable No [29] No [29]
Verifiably no backdoor in the project's own source code Invalid [30] Invalid [30] Invalid [30] Invalid [30] Invalid [30]
Verifiably vulnerability-free No [31] No [31] No [31] No [31] No [31]
Verifiably no hidden source code [32] in upstream distribution / binaries [33] No [34] No [34] No [34] No [34] No [34]
Project's binary builds are verifiably created from project's own source code (no hidden source code [32] in the project's own source code) No (deprecated) [35] No Yes No Not applicable [28]

Some readers might be curious why Whonix was previously verifiable, while Debian and other distributions are not. In short, this is because Whonix is uncomplicated by comparison. In simple terms, Whonix is a collection of configuration files and scripts, and the source code does not contain any compiled code and so on. In contrast, Debian is a full operating system, without which Whonix would not exist. [36]

This feature was first made available in Whonix 8. Only users who download a new image can profit from this feature. [37] It is not possible to audit versions older than Whonix 8 with this script. [38]

This is only an an introduction to this topic; see Verifiable Builds for full details.

Verifiable Whonix ™ Debian Packages[edit]

verifiable builds warning icon Warning:

Deprecated. A dedicated maintainer is required.

This has been deprecated because it is difficult to implement before the experimental, Debian reproducible toolchain is merged into the stable release. [39] For full details on this topic, see Verifiable Whonix ™ Debian Packages.

Whonix ™ Updates[edit]


An optional updater has been available in Whonix ™ since version 6 of the platform. [40] When it comes to trust, there is a large difference between building Whonix ™ from source code and using the Default-Download-Version.

APT Repository and Binary Builds Trust[edit]

When Whonix ™ is built with the build script and the source code is verified to be non-malicious and reasonably bug-free, Whonix ™ developers are unable to access the system. On the other hand, if Whonix ™ APT repository is enabled, developers holding a Whonix ™ repository signing key could release a malicious update to gain full access to the machine(s). [41]

Even if the Whonix ™ APT repository is not used with the Default-Download version, it is still theoretically possible for Whonix ™ developers to sneak a backdoor into the binary builds which are available for download. [42] Although an unpleasant threat, using Whonix ™ APT repository poses a greater risk: a malicious Whonix ™ developer might sneak in a backdoor at any time.

It is easier to sneak backdoors into binary builds, since they contain compiled code in binary packages which are downloaded from the Debian repository when built. The actual Whonix ™ deb packages do not yet have any compiled code, and consist of only configuration files, scripts, and comments. [43] The lack of compiled code inside Whonix ™ deb packages at present might make it easier for auditors searching for a backdoor in updated deb packages, [44] compared to the binary builds.

APT Repository Default Settings[edit]

Non-Qubes-Whonix ™:

  • Building from source code: Whonix ™ APT Repository is disabled by default. [45]
  • Default binary download: Whonix ™ APT Repository is enabled by default.

Qubes-Whonix ™:

  • Qubes/Install: Whonix ™ APT Repository is enabled by default.
  • Building from source code: Whonix ™ APT Repository is enabled by default. [46]

Most users will have the Whonix ™ APT repository enabled. This means when updated Whonix ™ debian packages are uploaded to the Whonix ™ APT repository, these packages will be automatically installed when the system is upgraded. [47] If this behavior is unwanted, this can be disabled. Refer to the previous section outlining security implications before proceeding.

Security Conclusion[edit]


  • *: poor security.
  • ****: best security.

Table: Build and APT Repository Security Comparison

Binary Download with Whonix ™ APT Repository Binary Download without Whonix ™ APT Repository Built from Source Code and Whonix ™ APT Repository Enabled Built from Source Code and Whonix ™ APT Repository Disabled
Security * ** * ****
Convenience **** * ** *

In summary:

  • The Whonix ™ binary download using the Whonix ™ APT repository is the most convenient method, but also the least secure.
  • It is somewhat safer to use the Whonix ™ binary download and then disable the Whonix ™ APT repository. However, the user must then manually download updated Whonix ™ deb packages upon release, and independently verify and install them.
  • The greatest security comes from building Whonix ™ and updated packages from source code, particularly if the source code is verified before building Whonix ™.


What Digital Signatures Prove[edit]

See Verifying Software Signatures for details on what digital signatures prove. In short, a user must be careful to ensure the public keys that are used for signature verification are the bona fide Whonix ™ key pair belonging to Patrick Schleizer.


TLS, SSL and HTTPS are all flawed since they rely on the vulnerable Certificate Authority (CA) model; see here for further details and SSL/TLS alternatives. [48]

Evil Developer Attack[edit]


An "evil developer attack" is a narrow example of an insider threat: [49]

Software development teams face a critical threat to the security of their systems: insiders.


An insider threat is a current or former employee, business partner, or contractor who has access to an organization’s data, network, source code, or other sensitive information who may intentionally misuse this information and negatively affect the availability, integrity, or confidentiality of the organization’s information system.

In the case of software, a disguised attack is conducted on the integrity of the software platform. While this threat is only theoretical, it would be naive to assume that no major software project has ever had a malicious insider. Whonix ™ and all other open source software projects face this problem, particularly those that are focused on anonymity such as VeraCrypt, [50] Tails, I2P, The Tor Project and so on.

Attack Methodology[edit]

A blueprint for a successful insider attack is as follows:

  1. Either start a new software project or join an existing software project.
  2. Gain trust by working hard, behaving well, and publishing your sources.
  3. Build binaries directly from your sources and offer them for download.
  4. Attract a lot of users by making a great product.
  5. Continue to develop the product.
  6. Make a second branch of your sources and add malware.
  7. Continue to publish your clean sources, but offer your malicious binaries for download.
  8. If undetected, a lot of users are now infected with malware.

An evil developer attack is very difficult for end users to notice. If the backdoor is rarely used, then it may remain a secret for a long time. If it was used for something obvious, such as adding all the users to a botnet, then it would be quickly discovered and reported on.

Open source software has some advantages over proprietary code, but certainly not for this threat model. For instance, no one is checking if the binaries are made from the proclaimed source and publishing the results, a procedure called "deterministic builds".[51] [52] This standard is quite difficult to achieve, but is being worked towards. [53]

Related Attacks[edit]

While most security experts are focused on the possibility of a software backdoor, other insider attacks can have equally deleterious effects. For instance, the same methodology can be used to infiltrate a targeted project team but in a role unrelated to software development; for example, as a moderator, site administrator, wiki approver and so on. This approach is particularly effective in smaller projects that are starved of human resources.

Following infiltration, disruption is caused within the project to affect productivity, demoralize other team members and (hopefully) cause primary contributors to cease their involvement. For example, using a similar blueprint to that of the evil developer attack, a feasible scenario is outlined below:

  1. Join an existing software project as a general member.
  2. Gain trust by working hard, behaving well, assisting readily in forums, making significant wiki contributions and so on.
  3. Attract a lot of community admiration by outwardly appearing to be a bona fide and devoted project member.
  4. Eventually attain moderator, administrator or other access once team membership is extended. [54]
  5. Continue to behave, moderate and publish well.
  6. Once trust is firmly established, subtly undermine the authority, character and contributions of other team members. [55]
  7. If the insider threat is undetected for a significant period, this can lead to a diminished software product due to a fall in contributions in numerous domains and team ill will.


The insider threat nicely captures how difficult it is to trust developers or other project members, even if they are not anonymous. Further, even if they are known and have earned significant trust as a legitimate developer, this does not discount the possibility of serious mistakes that may jeopardize the user. The motives and internal security of everyone contributing to major software projects like Tor, distribution developers and maintainers, and the hundreds of upstream developers and contributors is a legitimate concern. [56]

The trusted computing base of a modern operating system is enormous. There are so many people involved in software and complex hardware development, that it would be unsurprising if none of the bugs in existence were intentional. While detecting software changes in aggregate may be easy (by diffing the hash sums), finding and proving that a change is a purposeful backdoor rather than a bug in well designed source code is near impossible.

Other Projects Discussing Trust[edit]

Footnotes / References[edit]

  1. Creator of the Linux kernel.
  3. On the flip-side, there is no guarantee that just because software is open to review, that sane reviews will actually be performed. Further, people developing and reviewing software must know the principles of secure coding.
  4. (w)
  5. Debian also participates in security standardization efforts and related overarching projects.
  6. And undoubtedly advanced adversaries.
  7. That said, a skilled, malicious coder is far more likely to introduce subtle errors that open non-obvious attack vectors.
  8. This is a good starting point to understand how Whonix ™ works.
  10. Meaning doubts should surface if a new canary was not issued for longer than 4 weeks.
  11. If issues arise with the server, this ensures the canary is always available online.
  12. This feature has been available since Whonix ™ 0.4.5
  13. Verifiable Builds allow auditors to check if there is hidden code inside Whonix ™.
  14. 14.0 14.1
  15. Whonix ™ developer (w), named proper in the past (w), renamed himself to adrelanos (w), published his OpenPGP key on 05/29/12 (w) (wiki history (w)). Revealed his identity on 01/18/14. (w) Patrick Schleizer posted his OpenPGP key transition message on 01/18/14, signed by both his old and new key. (w)
  17. This feature only adds security if people actually use it. Do not assume that someone else will do it for you
  18. Due to build machine compromise.
  20. Whonix is based on Debian.
  21. Some Debian developers are steadily working on this long-term project, see: Reproducible Builds.
  25. 25.0 25.1 Open Source software does not automatically prevent backdoors, unless the user creates their own binaries directly from the source code. People who compile, upload and distribute binaries (including the webhost) could add hidden code, without publishing the backdoor. Anybody can claim that a certain binary was built cleanly from source code, when it was in fact built using the source code with a hidden component. Those deciding to infect the build machine with a backdoor are in a privileged position; the distributor is unlikely to become aware of the subterfuge. Deterministic builds can help to detect backdoors, since it can reproduce identical binary packages (byte-for-byte) from a given source. For more information on deterministic builds and why this is important, see:
  26. See Tails Roadmap.
  27. See Deterministic Builds Part One: Cyberwar and Global Compromise and Deterministic Builds Part Two: Technical Details.
  28. 28.0 28.1 corridor only uses shell scripts.
  29. 29.0 29.1 29.2 29.3 To be fair, there are no deterministically built operating systems yet. It is a difficult process and takes a lot of effort to complete. While Debian has around 22,000 reproducible packages in mid-2018, this work has been ongoing since 2013 and is far from done.
  30. 30.0 30.1 30.2 30.3 30.4 The first form of backdoor is a vulnerability (bug) in the source code. Vulnerabilities are introduced either purposefully or accidentally due to human error. Following software deployment, an attacker may discover the vulnerability and use an exploit to gain unauthorized access. Such vulnerabilities can be cleverly planted in plain sight in open source code, while being very difficult to spot by code auditors. Examples of this type of backdoor include: The second form of backdoor is adding the full code (or binary) of a trojan horse (computer virus) to the binary build, while not publishing the extra source code and keeping it secret. This process can only be detected with deterministic builds.
    It is therefore impossible to claim that non-trivial source code is backdoor-free, because backdoors can be hidden as vulnerabilities. Auditors scrutinizing the source code can only state an opinion about the quality of the source code, and eventually report vulnerabilities if/when they are identified. Assertions that source code is free of computer viruses (like trojan horses) is the only reasonable assertion that can be made.
  31. 31.0 31.1 31.2 31.3 31.4 Although theoretically possible, there are no mathematically proven bug-free operating systems yet.
  32. 32.0 32.1 Hidden source code is defined as code which is added by an adversary. They may have: compromised a build machine, conducted compiling prior to the binary build process, or be responsible for building the actual binary. The secret source code will remain unpublished and it will appear (or be claimed) that the software was built from the published source code. Reliably detecting such hidden code - added on purpose or due to build machine compromise - requires comparison with deterministic builds, which are discussed above. Other methods like watching network traffic are less reliable, since a backdoor can only be spotted when it is used. Backdoors are even less likely to be found through reverse engineering, because very few people are using a disassembler.
  33. The upstream distribution is the distribution on which the project is based. Whonix and Tails are based on Debian, thus Debian is their upstream distribution. QubesOS TorVM is based on Qubes OS, which is itself based on Fedora and Xen.
  34. 34.0 34.1 34.2 34.3 34.4 No, since the upstream software is not deterministically built. See above to learn about deterministic builds
  35. See verifiable builds.
  36. Whonix relies on the tireless efforts of Debian and other upstream projects.
  37. Because in order to implement the verifiable builds feature, a lot of non-deterministic, auto-generated files are removed at the end of the build process and re-created during first boot.
  38. It is not actually impossible, but it would require significant effort.
  39. Old advice: Since Whonix 7.5.2, all Whonix Debian Packages have been deterministically built. This means if the Whonix Debian Packages 7.5.2 are built from source code, and 7.5.2 downloaded from the Whonix Debian repository, it is possible to diff the checksum (for example the sha512sum) of those files and they should match. This has been deprecated because of a dpkg bug. The estimate of the Installed-Size can be wrong by a factor of 8, or a difference of 100MB (note: this bug has now been resolved). Different underlying file systems cause different file sizes, leading to checksums not matching.
  40. When Whonix ™ APT repository is disabled, there is no updater - as was the case in Whonix ™ 0.5.6 and below.
  41. At the moment, Whonix ™ developer Patrick Schleizer is the only one holding the Whonix ™ APT repository OpenPGP signing key.
  42. See the Verifiable Builds section for further details.
  43. Although these could change with a malicious update.
  44. Unless it is a targeted attack.
  45. Since Whonix ™ version 7.3.3
  46. To disable this setting, see: qubes-template-whonix: builder.conf, and set WHONIX_APT_REPOSITORY_OPTS = off
  47. After running sudo apt-get update && sudo apt-get dist-upgrade manually or via a GUI updater.
  48. Whonix ™ developers place little trust in the CA model. Even if the numerous implementation problems were solved, such as problematic revocation and the ability for every CA to issue certificates for anything (including "*"), third party trust cannot be established. Until an alternative arrives and is widely adopted, everybody has to rely upon SSL/TLS to some extent.
  50. TrueCrypt has been discontinued.
  53. Interested readers can investigate its complexity by searching with the phrase "trusting trust".
  54. The time period is likely to be shorter for smaller projects, perhaps less than 12 months.
  55. For example, by casting unjustified aspersions.
  56. In the case of Whonix ™, binaries are not distributed nor created. Only unmodified upstream binaries are distributed, along with shell scripts. This claim is much easier to verify than if Whonix ™ were distributing binaries from project source code.


Whonix ™ Trust wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix ™ Trust wiki page Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP <>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.

No user support in comments. See Support. Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

We are looking for help in managing our social media accounts. Are you interested?

https | (forcing) onion

Follow: Twitter | Facebook | | Stay Tuned | Whonix News

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian. Debian is a registered trademark owned by Software in the Public Interest, Inc.

Whonix ™ is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

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. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.