Update philosophy flaw

[adrelanos]

@Sks

When i use the updater where can i see the updated code is there like a link it pulls the code from like git clone qubes/qubesupdate update branch?

No. That’s not how it works. You’ll receive binary packages (pre-built programs, like store-bought meals) from the binary repository (the official “software store”). The git clone (copying the recipe, i.e. source code) already happened earlier on the developer’s build machine (their kitchen).

It’s binary distribution, not a source-based distribution. (And I am not saying it should be a source-based distribution, that comes with different huge disadvantages such as higher disk space requirements (for build dependencies) and very long complication times.)

@adw

@Sks

Still the qubes team could be compromised is there any protection against a malicious developer to push code that could be malicious?

The developers review each other’s work, and since the code is open source, anyone else can review their work too.

A threat model which isn’t very well addressed at this time is developer build machine compromise. That means the computer used by developers to create binary packages (their “kitchen”) might get hacked.

• Developers do review each other’s source code (the recipe).
• Developers, at the time of writing, do not systematically review the binary packages all the time (the cooked meals).

Open Source helps with reviewing binaries too, because it enables reproducible builds (ensuring the same recipe always produces the same meal). But until reproducible builds and independent rebuilders are fully implemented, a compromised developer build machine would be fatal.

I am describing this threat model in more detail here:
Qubes OS could be honeypot? - #119 by adrelanos

@Quben

@solene

no, except if you build all your software from sources and that you review all changes, instead of using pre-built programs

This would be the best defense against a supply chain attack. Don’t forget to audit the entire Qubes code and compile your own ISO from scratch.

It may be a bold claim, but I will back it up:

• Almost nobody is building a Qubes ISO (installation image, like the full operating system “box”) fully from source code without using and trusting binaries provided by Qubes.
• On top of that, I am not aware of anyone who claims to always update from source code rather than binaries.

While doable in theory for developers, I don’t think it’s being done in practice at this time.

What “building from source code” means in the context of building Linux distributions from source code is not well defined.

@adrelanos

How Much Is Accomplished by Building Qubes Images Using Qubes Builder?

It’s nice to do that, but not much is accomplished. Even if using Qubes builder, you’ll most likely still be using binaries that you have not built yourself. Evidence?

Just search Qubes source code for deb.qubes-os.org. For example, see: QubesOS/qubes-builder-debian/blob/main/template_debian/distribution.sh

deb [arch=amd64] [https://deb.qubes-os.org/r${USE_QUBES_REPO_VERSION}/vm](https://deb.qubes-os.org/r$%7BUSE_QUBES_REPO_VERSION%7D/vm) ${DIST_CODENAME} main

What does that mean? That Qubes binary repository is being used during the Qubes image build process. Therefore, not touching any binaries created by Qubes is already extremely difficult.

For a person to claim they’ve built a Qubes ISO or at least a Qubes Template without using any pre-built Qubes binaries, they would have to explain how they avoided using the Qubes repository during the build process. [1]

This is possible in theory, but if someone has done it, please Open Source your build scripts and consider upstreaming these to Qubes.

As for reproducible builds, ticket Make the whole qubes-builder deterministic · Issue #816 · QubesOS/qubes-issues · GitHub hasn’t seen any development activity since 2021. If progress is being made, I am not aware of it. This is not to criticize Qubes. Maintaining Qubes is a tremendously huge task. This simply shows that there are opportunities for improvement. Developer contributions are needed and welcome.

Now suppose we had reproducible builds and rebuilders. That would mean multiple independent parties could continuously verify that the repository really is reproducible, that every binary matches its source code, without any unexpected (malicious) differences.

This would be like several independent chefs each following the same recipe and checking that the meals all come out identical, making it harder for anyone to secretly slip poison into just one batch.

What should happen if a backdoor was found? One idea: multiple trusted developers could publish a “halt flag” that temporarily prevents users from updating until they manually override, or until the developers revoke the flag if it turned out to be an explained, harmless difference (for example, something trivial like timestamps).

This issue is unspecific to Qubes. The same question applies to Debian, Fedora, or other Linux distributions: How do I build everything from source code without relying on any of their pre-built binaries during the process? In practice, it is even less likely that anyone is doing this outside of theory.

The feature we are really lacking and would like to have are bootstrappable builds.

Bootstrappability means the ability to build a complete operating system (or software stack) entirely from source code, starting with only minimal, independently verifiable binaries.

---

[1] Lines such as:

deb [arch=amd64] [https://deb.qubes-os.org/r${USE_QUBES_REPO_VERSION}/vm](https://deb.qubes-os.org/r$%7BUSE_QUBES_REPO_VERSION%7D/vm) ${DIST_CODENAME} main

in QubesOS/qubes-builder-debian/blob/main/template_debian/distribution.sh demonstrate that the Qubes build process still pulls in pre-built binaries from the Qubes repository.