{{Header}} {{Title|title= Placing Trust in {{project_name_short}} }} {{#seo: |description=Is {{project_name_short}} trustworthy? Is there a backdoor in {{project_name_short}}? How does {{project_name_short}} protect itself from backdoors? |image=Candle-335965-640.jpg }} [[File:Candle-335965-640.jpg|thumb|200px]] {{intro| Is {{project_name_short}} trustworthy? Is there a backdoor in {{project_name_short}}? How does {{project_name_short}} protect itself from backdoors? }} = Trust Documentation = {{upstream_wiki}} == Trusting Tor == {{project_name_short}} anonymity is based on Tor, which is developed by [https://www.torproject.org/ The Tor Project]. Tor is a [[Why_does_{{project_name_short}}_use_Tor|mature anonymity network with a substantial user base]], and it has developed a solid reputation after around two decades 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. And undoubtedly advanced adversaries. 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. That said, a skilled, malicious coder is far more likely to introduce subtle errors that open non-obvious attack vectors. Theories about deliberate backdoors in Tor are considered highly speculative and lacking any credible basis. == Trusting {{project_name_short}} == In one sense, {{project_name_short}} 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 {{project_name_short}} trustworthiness is also necessary. The {{project_name_short}} project was founded on 11 January, 2012. It previously existed under [[History|different project names]], including TorBOX and aos. As mentioned earlier, {{project_name_short}} is Freedom Software which makes the source code available for inspection. In the main, {{project_name_short}} is comprised of specifications for which Debian software packages should be installed and their appropriate configuration. See also [[Security Reviews and Feedback|this list of notable reviews and feedback about the security of {{project_name_short}}]]. With a relatively small development team and estimated user base, the "many eyeballs" theory may work against {{project_name_short}} 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 {{project_name_short}} specification and design [[Design|here]]. This is a good starting point to understand how {{project_name_short}} works. With these factors in mind, the reader can now make an informed decision about the trustworthiness of {{project_name_short}}. {{Anchor|canary}} == {{project_name_short}} Warrant Canary == [[File:Forestcanary.jpg|thumb|Canary|250px]] The {{project_name_short}} [https://en.wikipedia.org/wiki/Warrant_canary warrant canary] is intended to provide a mean of communication to users in the event {{project_name_short}} 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 and/or signify, this confirms that no warrants have been served on the {{project_name_short}} project. Note: the canary date of issue is represented by the gpg signature date. A new canary should be released within 4 weeks. Meaning doubts should surface if a new canary was not issued for longer than 4 weeks. The canary and signature are available here: * Canary text file: {{Archive_link |url=https://download.{{project_clearnet}}/developer-meta-files/canary/canary.txt |onion=http://download.{{project_onion}}/developer-meta-files/canary/canary.txt v3 |text=canary.txt }} * OpenPGP signature: {{Archive_link |url=https://download.{{project_clearnet}}/developer-meta-files/canary/canary.txt.asc |onion=http://download.{{project_onion}}/developer-meta-files/canary/canary.txt.asc |text=canary.txt.asc }} * signify signature: {{Archive_link |url=https://download.{{project_clearnet}}/developer-meta-files/canary/canary.txt.sig |onion=http://download.{{project_onion}}/developer-meta-files/canary/canary.txt.sig |text=canary.txt.sig }} As a backup, the canary and signature are also available on github: If issues arise with the {{project_clearnet}} server, this ensures the canary is always available online. * https://github.com/{{project_name_short}}/canary 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. Related: * [https://forums.whonix.org/t/whonix-warrant-canary/3208 Forum Discussion] * [[Dev/Warrant Canary Draft]] == Trusting the Download Location == 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 {{project_name_workstation_long}} and {{project_name_gateway_long}} images using the available OpenPGP signatures. This feature has been available since {{project_name_short}} 0.4.5. All source code tags for releases are OpenPGP-signed by lead {{project_name_short}} developer Patrick Schleizer. In order of increasing security, the {{project_name_short}} images can be: # Downloaded via {{Code|https://www.{{project_clearnet}}}}. TLS provides some trust and integrity of the hash file, but it is still advisable to check the site's certificate and perform [[Verifying Software Signatures|digital software signature verification]] ([[Verify the images|instructions]]). # Downloaded over the [http://www.{{project_onion}} {{project_name_short}} v3 onion address] with Tor Browser before digital software signature verification. Onion addresses provide a higher standard of authentication than clearnet addresses. # [[Dev/Build Documentation|Built from source]] since it is a relatively easy procedure. [[Trust#Verifiable_Builds|Verifiable Builds]] allow auditors to check if there is hidden code inside {{project_name_short}}. == Trusting {{project_name_short}} Images == '''Table:''' ''Maintainer Overview - Platform, Source Code, Binary Images, Permissions'' {| class="wikitable" style="background-color: #fff;text-align: center" ! ! {{project_name_short}} VirtualBox ! {{project_name_short}} KVM ! {{q_project_name_long}} ! Built from Source Code |- ! Source Code Creation | Patrick | Patrick | Qubes project and Patrick | Patrick |- ! Source Code Trust | Patrick | Patrick | Qubes project and Patrick | Patrick |- ! Binary Image Creation | Patrick | Patrick | Qubes project Builds can be [[Dev/Qubes#Official_Builds|initiated]] by Patrick but the template build server and template repository are hosted by the Qubes project. | - |- ! Binary Images Trust | Patrick | Patrick | Qubes project and Patrick | - |- ! Package Upgrades Creation | Patrick | Patrick | Qubes project and Patrick | - |- |} Since [[About#Based_on_Debian|{{project_name_short}} is based on Debian]], Debian releases package upgrades. See also: [[#Trusting Debian GNU/Linux|Trusting Debian GNU/Linux]]. == Trusting Tor Browser == [[Tor Browser]]: * Developed by The Tor Project (TPO). * Pre-installed inside {{project_name_workstation_short}}. Not in {{project_name_workstation_short}} CLI. * On the {{project_name_short}} Intel / amd64 architecture: ** [[Tor Browser#Tor Browser Internal Updater|Tor Browser Internal Updater]] downloads Tor Browser which is built by TPO from the TPO website. ** [[Tor Browser#Tor Browser Downloader by {{project_name_short}}|Tor Browser Downloader by {{project_name_short}}]] downloads from the TPO website. * On the {{project_name_short}} arm64 architecture: ** Links / status on arm64 architecture support generally: [[Dev/Porting]] ** [[Tor Browser#Tor Browser Internal Updater|Tor Browser Internal Updater]] is unavailable? ** [[Tor Browser#Tor Browser Downloader by {{project_name_short}}|Tor Browser Downloader by {{project_name_short}}]] downloads an unofficial build on [https://sourceforge.net/projects/tor-browser-ports sourceforge]. ** Forum discussion: [https://forums.whonix.org/t/arm64-tor-browser-maintainer/11786 ARM64 Tor Browser Maintainer] = Verifiable Builds = == Verifiable .ova Releases == {{Verifiable_Ovas_Introduction}} This is only an an introduction to this topic; see [[Verifiable Builds]] for full details. == Verifiable {{project_name_short}} Debian Packages == {{Verifiable_Pkgs_Introduction}} For full details on this topic, see [[Verifiable Builds#Verifiable {{project_name_short}} Debian Packages|Verifiable {{project_name_short}} Debian Packages]]. = {{project_name_short}} Updates = == Introduction == An optional updater has been available in {{project_name_short}} since version 6 of the platform. When {{project_name_short}} APT repository is disabled, there is no updater - as was the case in {{project_name_short}} 0.5.6 and below. When it comes to trust, there is a large difference between building {{project_name_short}} from source code and using the Default-Download-Version. == APT Repository and Binary Builds Trust == When {{project_name_short}} is built from source code using the build script and the source code is audited by the builder to be non-malicious and reasonably bug-free, {{project_name_short}} developers are unable to access the system. On the other hand, if {{project_name_short}} APT repository is enabled, developers holding a {{project_name_short}} repository signing key could release a malicious update to gain full access to the machine(s). At the moment, {{project_name_short}} developer Patrick Schleizer is the only one holding the {{project_name_short}} APT repository OpenPGP signing key. Even if the {{project_name_short}} APT repository is not used with the Default-Download version, it is still theoretically possible for {{project_name_short}} developers to sneak a backdoor into the binary builds which are available for download. See the [[Verifiable Builds]] section for further details. Although an unpleasant threat, using {{project_name_short}} APT repository poses a greater risk: a malicious {{project_name_short}} 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. == APT Repository Default Settings == [[Non-Qubes-Whonix|{{non_q_project_name_short}}]]: * [[Dev/Build Documentation|Building]] from source code: {{project_name_short}} APT Repository is ''disabled by default.'' Since {{project_name_short}} version 7.3.3 * Default [[Download|binary download]]: {{project_name_short}} APT Repository is ''enabled by default.'' [[Qubes|{{q_project_name_short}}]]: * [[Qubes/Install]]: {{project_name_short}} APT Repository is ''enabled by default.'' * [[Dev/Build Documentation|Building]] from source code: {{project_name_short}} APT Repository is ''enabled by default.'' To disable this setting, see: [https://github.com/{{project_name_short}}/qubes-template-whonix qubes-template-whonix]: in file TODO (please ask Qubes) and set DERIVATIVE_APT_REPOSITORY_OPTS = off Most users will have the {{project_name_short}} APT repository enabled. This means when updated {{project_name_short}} debian packages are uploaded to the {{project_name_short}} APT repository, these packages will be automatically installed when the system is upgraded. After running sudo apt update && sudo apt full-upgrade manually or via a GUI updater. If this behavior is unwanted, this can be [[Project-APT-Repository#Disable_{{project_name_short}}_APT_Repository|disabled]]. Refer to the previous section outlining security implications before proceeding. == Security Conclusion == Legend: * *: poor security. * ****: best security. '''Table:''' ''Build and APT Repository Security Comparison'' {| class="wikitable" style="background-color: #fff;text-align: center" ! ! Binary Download with {{project_name_short}} APT Repository ! Binary Download without {{project_name_short}} APT Repository ! Built from Source Code and {{project_name_short}} APT Repository Enabled ! Built from Source Code and {{project_name_short}} APT Repository Disabled |- ! Security | style="background-color: {{Red}}"| * | style="background-color: {{Yellow}}"| ** | style="background-color: {{Red}}"| ''*'' | style="background-color: {{Green}}"| **** |- ! Convenience | style="background-color: {{Green}}"| **** | style="background-color: {{Red}}"| ''*'' | style="background-color: {{Yellow}}"| ** | style="background-color: {{Red}}"| * |- |} In summary: * The {{project_name_short}} binary download using the {{project_name_short}} APT repository is the most convenient method, but also the least secure. * It is somewhat safer to use the {{project_name_short}} binary download and then disable the {{project_name_short}} APT repository. However, the user must then manually download updated {{project_name_short}} deb packages upon release, and independently verify and install them. * The greatest security comes from [[Dev/Build_Documentation|building {{project_name_short}}]] and updated packages from source code, particularly if the source code is verified before building {{project_name_short}}. = Appendix = == What Digital Signatures Prove == {{always_verify_signatures_reminder}} See [[Verifying_Software_Signatures|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 [[Signing Key|{{project_name_short}} key pair]] belonging to the {{project_name_short}} developer of the component specific component. At time of writing there are two different components and signing keys. * [[Main/Project Signing Key|{{project_name_short}} Main, VirtualBox, KVM, APT Repository and Source Code Signing Key]] = Footnotes = {{reflist|close=1}} = License = {{License_Amnesia|{{FULLPAGENAME}}}} {{Footer}} [[Category:Documentation]]