People always say to never install unreviewed code in dom0.
And while I was installing fish I realized, I don’t even know what the proper process would be…
What counts as proper review? Running though test environments, read everything in the git repo + package build infos then compile it yourself? Or only install stuff you have written yourself? How does the Qubes team deem packages safe?
Ultimately, you should review the whole supply chain required to build the binary, and compile all of this from sources. This is not humanly possible.
For very small programs, it’s possible to read the source code and compile it locally (given you already trust the compiler, and all code that was used to compile the compiler).
Then you can also trust a common project to be reasonably safe (I mean, it does not carry a malware payload), and that it was genuinely packaged for fedora. But that’s it…
Yeah suspected this. Maybe something will change with more funding in FOSS and more focus on supply chain security. ( Reproducible builds, SBOMs…)
Until then I will just enjoy the quality of life my compromised system gives me 
I’m not convinced reproducible builds or SBOM will help, you still need to trust someone if you don’t want to review and build everything yourself.
reproducible builds do help. Imagine for example if intel management engine and AMT and that minix os in the intel me was all reproducible and open source and reproducible, that would be amazing!
And with reproducible builds you can know if the code is the same that’s on the github page. If it’s not reproducible then the built app they give you might not be the same as the open source code on the github page (for example adding a telemetry module secretly to built app).
And if something goes wrong, like your whole system gets hacked. Then you can start in depth going through all the code to find out what caused it. Most likely you wouldn’t be doing this alone because if it’s reproducible and using tor to install and update then it’s unlikely they’ve targeted only you with bad version. So it would become a community or maybe federal project to go through the reproducible code. But if it’s not reproducible there’s not so much to do. You can try reverse engineering but that’s 1 million times more difficult.
the thing is “reproducible against what”? You need to trust someone else who can report the reproducible end result for comparison.
do you mean for example that we are trusting debian to properly and honestly verify the reproducible builds? I haven’t looked into that process yet so I can see that being a problem but I think it’s still better than there not being any reproducible builds at all. And in worst case we can use that process as a stepping stone to an even better system.
But ideally if you can download the source code, then you can easily compare it to the code on github to see it’s exactly the same. Yes you use a program to do the comparison but this program should have been reproducibly built as well. But then as you go deeper into supply chain then it keeps getting harder and at one point it’s not possible any longer to verify.
The difficulties with this is the deep state is our enemy. They hate FOSS. They want backdoors in everything. For example chatcontrol in EU. And the reason everyone is paranoid about intel AMT is because NSA asked intel to put a backdoor in it. And then mossad who have admitted in their 60 minutes interview they make shell companies for shell companies and pretend to be normal businesses just to they can sell their compromised versions of products that used to be good. USA’s deep state is all about doing supply chain attacks against the people. You don’t need privacy if you have nothing to hide.
And this powerful state actor have unlimited money to spend on propaganda and bribing and blackmailing. They infect FOSS projects, get their own useful idiots in, get the foss legends out. That’s why important things like .onion support, reproducible builds, developer anonymity, are so slow to make any progress on.
We just need to keep this bigger threat in mind and try our best to keep improving these things the deep state don’t want us to improve. We can’t let them herd us in the direction they are trying to distract us to go to just because its easier when they don’t resist us.
Reproducible builds have its challenges right now but that’s because of the deep state. We need to keep making embracing reproducible builds and keep making progress on it.
Well, no.
For end users, you already trust the developer/packager who has created the
package(generic term) from the source code.
Reproducible builds help those developers ensure that their build
process is secure, and that the end result matches the source code. This
secures the build pipeline.
Any one with the relevant skills can create the relevant build
environment, create the package, and test against the published product.
Differences are immediately obvious and reportable, providing a 3rd
party confirmation that the package has not been tampered with.
For end users, reproducible builds don’t require “someone else” who will
be trusted to test and report the result for comparison. They
enhance the trust that those end users have in the developer/packager.
The wider community of developers and testers is able to confirm that
the developer/packagers build process is to be trusted. (N.B “is able to”
does not mean “will” - just as having eyes on the source code does not
mean that errors/security holes will be found.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.