{| class="wikitable" style="text-align: center;"
|- style="background-color: #f9f9f9"
| style="height: 30px;width:250px"|
| '''{{project_name_short}}'''
| '''Tails'''
| '''Tor Browser'''
| '''Qubes OS TorVM'''
| '''corridor'''
|-
| style="height: 27px;background-color: #f9f9f9"| Deterministic builds [
Open Source software does not automatically prevent [https://en.wikipedia.org/wiki/Backdoor_%28computing%29 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:
* [https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html liberationtech mailing list: Deterministic builds and software trust].
* [https://gitian.org/ gitian.org]
* As Mike Perry has observed: {{Code|Current popular software development practices simply cannot survive targeted attacks of the scale and scope that we are seeing today.}} See: [https://blog.torproject.org/deterministic-builds-part-one-cyberwar-and-global-compromise/ Deterministic Builds Part One: Cyberwar and Global Compromise].
* [https://wiki.debian.org/ReproducibleBuilds The Debian wiki tracking progress / development efforts to implement Reproducible Builds for all packages].
]
| {{No}}
| {{No}} (planned) [
See [https://gitlab.tails.boum.org/groups/tails/-/milestones Tails Roadmap].
]
| {{Yes}} [
See [https://blog.torproject.org/deterministic-builds-part-one-cyberwar-and-global-compromise/ Deterministic Builds Part One: Cyberwar and Global Compromise] and [https://blog.torproject.org/deterministic-builds-part-two-technical-details/ Deterministic Builds Part Two: Technical Details].
]
| {{No}}
| {{BlueBackground}} Not applicable [corridor only uses shell scripts.
]
|-
| style="height: 27px;background-color: #f9f9f9"| Based on a deterministically built [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 [https://wiki.debian.org/ReproducibleBuilds 25,000 reproducible packages] in mid-2021, this work has been ongoing since 2013 and is far from done.
]
| {{No}} [
The first form of [https://en.wikipedia.org/wiki/Backdoor_(computing) backdoor] is a [https://en.wikipedia.org/wiki/Vulnerability_(computing) 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 [https://en.wikipedia.org/wiki/Exploit_(computer_security) exploit] to gain unauthorized access. Such vulnerabilities can be cleverly [https://security.stackexchange.com/questions/42318/hiding-backdoors-in-open-source-code-in-other-languages-than-c-and-c planted in plain sight] in open source code, while being very difficult to spot by code auditors. Examples of this type of backdoor include:
* [https://lwn.net/Articles/57135/ An attempt to backdoor the kernel].
* The [https://www.theregister.com/2008/05/21/massive_debian_openssl_hangover/ Debian SSL debacle]; many argued that this wasn't a bug but in fact a backdoor, as it hadn't been spotted for several years.
The second form of backdoor is adding the full code (or binary) of a [https://en.wikipedia.org/wiki/Trojan_horse_(computing) 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.
| {{BlueBackground}} Invalid [Although theoretically possible, there are no mathematically proven [https://www.drdobbs.com/cpp/100-verifiable-bug-free-code-is-possible/228701189 bug-free] operating systems yet.]
| {{No}} [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 [https://en.wikipedia.org/wiki/Reverse_engineering reverse engineering], because very few people are using a [https://en.wikipedia.org/wiki/Disassembler disassembler].
] in upstream distribution / binaries [The upstream distribution is the distribution on which the project is based. {{project_name_short}} 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.
]
| {{No}} [No, since the upstream software is not deterministically built. See above to learn about deterministic builds
]
| {{No}} [
See [[Trust#Verifiable Builds|verifiable builds]].
]
| {{No}}
| {{Yes}}
| {{No}}
| {{BlueBackground}} Not applicable