I think that qubes os is the most secure os on the planet but i have a question on the update. Qubes is open source but it would be great to see the update code that is updated for the community to validate that it is not malicious. There could be a hack or compromise in the servers that push the update and cause harm. My question is why isn’t this implemented?
The updates signatures are checked to verify their authenticity:
So you only need to trust that the machine that developers use to build and sign the packages is not compromised.
2 Likes
Still the qubes team could be compromised is there any protection against a malicious developer to push code that could be malicious?
no, except if you build all your software from sources and that you review all changes, instead of using pre-built programs
You can already see all the code on GitHub since, as you pointed out, it’s open source.
As for the community validating that it’s not malicious, that would require getting enough volunteers from the community with the required expertise and coordinating them to spend their time and effort on every update. That would be a significant social and logistical challenge. You can see a similar effort underway here: Qubes code audit - #11 by illuminati
No, updates are cryptographically signed. If Qubes OS can’t validate the signature on an update, it will reject the update, so that wouldn’t work.
The most important part (cryptographically-signed updates) is already implemented and has been since the beginning.
The developers review each other’s work, and since the code is open source, anyone else can review their work too.
We also have canaries:
2 Likes
@Sks, if you’re curious about the methodology Qubes OS uses to administer updates, here would be a good place to start:
qubes-mgmt-salt-dom0-update
I host a Qubes OS repo mirror, so I can vouch for this personally.
I’m also proud to do my part for the Qubes Community 
Let’s say that I decided to swap out some of the files with malicious ones. What would happen?
Check 1 - File Hashes
Sure, your Qubes OS machine would ask me for the files, and would download them from me, but it would also ask the official Qubes OS server for the hash of the original files.
Your Qubes OS machine would then hash the file it just downloaded from me, and compare the hashes. If they didn’t match, your machine would likely refuse to install them.
But, let’s just say that by pure luck, I managed to alter the file and keep the hash identical (which is supposed to be impossible, or difficult to the point where nobody would even bother).
Check 2 - Developer Signatures
Your Qubes OS machine would then ask the official Qubes OS server for the signature .asc file (or use the one installed in dom0 on every Qubes OS installation) to check if the update had been tampered with.
This is where my attempt would almost certainly fail 
…but let’s say that I managed to get hold of the Qubes OS developer PRIVATE key, and used it to sign my malicious packages.
What checks are left?
(Optional) Check 3 - Human Verification
At this stage, you now have a file where the automated mathematical checks passed, so the computer says the file is “good”, but you might still not be convinced (a healthy level of skepticism is always a good thing).
You could then:
- Unpack the packages and have a look at the contents yourself
- Install them on a test machine to see if they’re malicious
The last option is, of course, to NOT install the package
@adw is right. It really is a HUGE amount of work to do this. That’s why the code is all there for anyone to:
- Inspect themselves
- Add/Remove/Change any part they like/don’t like
- Build it themselves, with or without any alterations (like @solene said)
And just for completeness, and I know that someone will bring up supply chain attacks… 
But what if something malicious gets into a component or building block that Qubes OS gets form somewhere else…?
Well, then we;re all screwed, I guess…
…but it wouldn’t be any different on any other OS
But what if the Qubes devs did get compromised and start sending out fake canaries…?
Well, this would happen:
Someone would fork Qubes OS immediately, and we’d all move to the new fork.
This is the nature of open source, and was the case with Audacity, Firefox, Digger, and Ubuntu, as a few quick examples, but there are other examples, too.
They most certainly do, and they are very good at it, too
1 Like
Thank you for your awnser @alzer89, is there any updater links to github where i can see the code?
Everything is here:
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? What i mean is when i am updating can i see exactly what it uodates.
Thanks,
Yeah that’s kinda a problem with 99.999% of open source projects. This shit happens all the time, even with SSH relatively recently and everyone uses SSH. I’ve heard there are people out there that put malicious code in open source projects just for sport.
This isn’t the kind of problem you fix, it’s the kind of problem you guard against. If your life depends on a single system or a single piece of software then your days are counted. Don’t be that guy. Build walls and moats. Live long and prosper.
I know ain’t nobody going to listen anyway but I still have to issue this warning: if you are a developer looking to start a new project that has anything to do with privacy PLEASE for the love of god use TOR and be completely anonymous about it. You are a valid military target. Act like one. Privacy is currently getting rounded up worldwide, and look all of its top scientists are sitting ducks for CIA snipers to pick out in any order they choose.
edit: never mind; Tor is useless now 
you’re stuck uploading everything to public wifi (and don’t forget they’re watching you from space too)
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. (Ain’t nobody got time for that so just run it through an A.I. instead, one subroutine at a time.)
You’d have to figure out a way to speed up critical security patches, though. You don’t want to be left behind as the only vulnerable system left in the network. 
1 Like
Do you mean the protocol?
Yes, this does happen. Sometimes it’s a test, sometimes it slips through, sometimes it’s a regression, and sometimes it’s an attack. Unfortunately there are also people out there who simply enjoy destroying stuff. One of the reason why we can’t have nice things sometimes.
There have even been cases where academics have done it as part of a research study. The entire university is still banned from submitting commits to the Linux kernel, even today.
1 Like
Is it that the starting point or…
1 Like
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.)
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
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.
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.
3 Likes
You have no evidence for this at all.
I know people who work from the source code - usually if they want to
customise the install in some way for deployment. I used to do so myself,
but time constraints and other limits meant that the exercise was
pointless for me. (And I trusted the team more than I trusted my ability
to assess the code.)
It’s surprising, and quite worrying, that you should think this.
The references to deb.qubes-os.org in the build process are used to
provision the Debian templates with suitable repository definitions.
During the build of the template, locally built packages are installed,
and pre-built Qubes binaries are not. You can verify this by building the
templates and monitoring the traffic from the build machine.
Many people have done this using the existing qubes-builderv2 framework.
Note that I am not saying that the build does not use any prebuilt
binaries. But your suggested evidence does not provide any evidence
that it does.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
Example build log:
- Go to Qubes updates-status.
- Choose a recent Debian template build (for example, Debian 13 minimal build #5946).
- Open the corresponding build log (direct link).
- Click “view raw” (raw build log).
Search the build log for:
deb.qubes-os.org
You’ll find lines such as:
Get:4 https://deb.qubes-os.org/r4.3/vm trixie InRelease [4735 B]
https://deb.qubes-os.org/r4.3/vm trixie/main amd64 qubes-core-qrexec amd64 4.3.10-1+deb13u1 [37.4 kB].
This clearly demonstrates that pre-built Debian packages from the Qubes repository are indeed downloaded and installed.
What other evidence could I reasonably present, beyond the absence of claims that people are doing this?
I believe I phrased it carefully with “Almost nobody” and “I am not aware of anyone who claims”.
If you believe it could be worded even more cautiously or precisely, I welcome suggestions.
Understood. So, some individuals work from source but do not speak publicly about it. That supports my point: I never claimed it’s categorically impossible. Only that there’s no public discussion or documentation of it.
What does it mean to “work from source code”?
- Are they making small modifications, like customizing package lists or configuration files? That’s plausible.
- Are they avoiding all pre-built binaries from the Qubes project entirely? If so, how is this achieved?
Until such documentation or upstream contributions exist, this remains a largely theoretical debate with minimal practical relevance for most users.
Exactly and that is the core of my point.
I hope the build log excerpts above sufficiently clarify this point.
This is irrelevant. We are talking about users building packages and
templates from source, not automated builds withing the Qubes
infrastructure.
I look in a recent build log and there is no prebuilt package installed.
All packages are installed from file:/tmp/qubes_repo - the local
repository populated with the packages that I have built from source.
This is the default behavior - build the packages, and then build the
template using those packages. There is an option, clearly documented,
to use pre-built packages,use-qubes-repo, but it is not included in
the example configs except for Kali.
There’s little public discussion of builds at all. Since the normal
process is to build packages and then templates from those packages, you
would not expect people to comment on this.
Yes, they modify the packages and configuration as they need. Yes they
avoid pre-built binaries from the Qubes project entirely because this
is the expected and default behavior.
As I have said, those excerpts mean nothing. Excerpts from build logs
from users who have built templates using standard builder.yml drawn
from the examples will show the opposite.
**A standard template build does not use pre-built packages from the Qubes
project. Users are free to use such packages if they choose.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.