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.
1 Like
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:
@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
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