I think that âtrust nobodyâ is an oversimplification of what is stated. Letâs break it down:
We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised.
This is saying that Qubes OS is designed to operate under a certain assumption. What is that assumption? It is the assumption that âall relevant infrastructure is permanently compromised.â In order to understand this statement, we have to answer a few questions:
- What does âinfrastructureâ mean?
- Which infrastructure counts as relevant here?
- What does âcompromisedâ mean?
Letâs look to the next statement for answers:
This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads.
The fact that this sentence starts with âThis means that we assumeâŚâ shows that itâs here to clarify the previous statement. In particular, it clarifies and explains the assumption, mentioned in the previous sentence, under which Qubes OS is designed to operate.
âNO trust in any of the servers or services which host or provide any Qubes-related dataâ helps to answer the first question (âWhat does âinfrastructureâ mean?â). We see here that âinfrastructureâ refers to things like servers or services which host or provide data. These are the types of things weâre referring to when we say âinfrastructure.â
The phrases âQubes-related dataâ and âin particular, software updates, source code repositories, and Qubes ISO downloadsâ help to answer the second question (âWhich infrastructure counts as relevant here?â). We see that the relevant infrastructure is infrastructure used to host or provide Qubes and domU OS software updates (i.e., package repositories), Qubes source code repositories (e.g., GitHub), and Qubes ISO downloads (i.e., download mirrors). These are examples of infrastructure that count as relevant in the phrase ârelevant infrastructure.â
Given this context, the answer to the third question ("What does âcompromisedâ mean?) is now pretty clear. Itâs referring to scenarios in which someone uses the infrastructure to do something bad. For example, someone could hack into GitHubâs servers and try to mess with our source code, or a rogue employee at GitHub could do the same. We protect against this by cryptographically signing all of our code. This way, even if a hacker or rogue employee messes with our code on GitHub, weâll always be able to tell, and weâll know not to trust it. In other words, we donât treat GitHub as an authoritative source for our code or as the source of truth for anything.
Similarly, any of our download mirrors could be compromised. When you try to download a Qubes ISO, it could instead serve you a fake Qubes ISO with malware inside. We protect against this the same way, namely by cryptographically signing Qubes ISOs. By verifying the signature on your Qubes ISO after you download it, you can determine whether itâs genuine or a forgery, so youâll know whether to trust it.
What about software updates from package repositories? Same thing. Cryptographically signed. Youâre probably beginning to see a pattern here. 
We call this general philosophy or approach âdistrusting the infrastructure.â Here is our FAQ entry on it:
What does it mean to âdistrust the infrastructureâ?
A core tenet of the Qubes philosophy is âdistrust the infrastructure,â where âthe infrastructureâ refers to things like hosting providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc. As a project, we focus on securing endpoints instead of attempting to secure âthe middleâ (i.e., the infrastructure), since one of our primary goals is to free users from being forced to entrust their security to unknown third parties. Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).
Users can never fully control all the infrastructure they rely upon, and they can never fully trust all the entities who do control it. Therefore, we believe the best solution is not to attempt to make the infrastructure trustworthy, but instead to concentrate on solutions that obviate the need to do so. We believe that many attempts to make the infrastructure appear trustworthy actually provide only the illusion of security and are ultimately a disservice to real users. Since we donât want to encourage or endorse this, we make our distrust of the infrastructure explicit.
Now that we understand what the disclaimer means, letâs take note of what it does not say. It does not say that we place no trust in upstream projects that we rely on, e.g., Xen, Fedora, or Debian. It also does not say anything about the infrastructure that those upstream projects use, own, or rely on. It says that we place no trust in âservers or services which host or provide any Qubes-related data.â It does not say anything about servers or services that host or provide Xen-related data, for example.
In other words, we do not try to police other projects or force them to abide by our standards. Even if we wanted to, we could not do that. We canât force anyone else to do anything. All we can do is decide who we will trust, because we canât do everything ourselves. For example, we canât create and maintain the Linux kernel by ourselves. We canât create or maintain Xen by ourselves. Those are whole projects in themselves, and theyâre vastly larger than the Qubes OS Project. This is why âtrust nobodyâ is unrealistic.
If we tried to do everything by ourselves, it would be evidence that we donât really understand the nature of our own undertaking. As an analogy, it would be as if a small local militia in some town were to say, âWe donât trust the national military, so weâre going to defend the country all by ourselves.â Everyone can immediately see that itâs absurd and delusional for a small group of people with hand weapons to hope to defend against tanks, artillery, aircraft, warships, and ICBMs. Similarly, it would be absurd and delusional for us (the Qubes OS Project) to say, âWe donât trust the Linux Foundation, the Xen Project, the Fedora Project, the Debian Project, or anyone else, so weâre going to defend against cyberattacks all by ourselves.â
Now, you might say, âWell, I wouldnât expect you to write all the code yourself to replace those huge projects, but couldnât you at least check all the upstream code you use?â No, this is still a herculean undertaking that would be completely unrealistic for a project of our size. After all, there are multiple entire operating systems inside of Qubes OS, plus a hypervisor. Those gigantic upstream projects can barely even check all of their own code. Moreover, since most projects are not security-oriented, they probably never check their code in the way security researchers would (which is probably part of the reason projects and companies have bug bounties and why independent security researchers often discover major vulnerabilities).
âOkay, fine,â you might say, âbut you should at least just check the upstream code thatâs included in the Qubes TCB, right?!â At first glance, this might seem like an eminently reasonable request. Of course, we should check all the code in the Qubes TCB, shouldnât we? After all, isnât the whole point of Qubes to trust as little as possible? In theory, yes, but âtrust as little as possibleâ isnât the same as âtrust nobody,â and in the real world, âas little as possibleâ is still quite a lot. Since I am not an expert, I asked @Demi about this. Here is what she said:
No. We do not even review all of the attack surface, such as Xen, Linux blkback, and Pythonâs regular expression library. There is even attack surface we have no visibility into, such as CPU microcode and USB controller firmware.
Reviewing the entire software TCB is only practical in certain embedded systems, and even there only because these systems are vastly simpler. If the entire TCB is 50,000 lines of code on a microcontroller, then one really can read the entire codebase in a reasonable amount of time, at least if one has access to all of the source code. In Qubes OS, the attack surface alone is quite a bit larger than that, and the TCB is many orders of magnitude larger â it includes Xen, Linux, and every other piece of code that runs in dom0, as well as the toolchains used to build that code. This is at least tens of millions of lines of code, and that is before one gets into the firmware, microcode, and other stuff that Qubes OS doesnât even have visibility into, much less control over. Admittedly, not all of that code actually runs, but figuring out what does and does not is itself a nontrivial task.
In short, auditing the entire TCB is completely impractical, and auditing the entire attack surface would require far more resources than the Qubes OS Project has. If one wants to build a system people can actually use, one has to trust a lot of stuff.