That sounds wildly unnecessary and resource intensive tbh. You're already trusting their software, but you don't trust...what? Their server security? Their signing process? Their honesty about the open source code being what you're downloading? I'm really struggling to understand your thought process here.
this post was submitted on 12 Mar 2026
44 points (100.0% liked)
Privacy
47127 readers
1767 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 6 years ago
MODERATORS
Most people who build software from source do it for reasons other than trust. Could be for fun (I imagine the main reason why people do Linux From Scratch), could be for the same reason that compels some people to use Gentoo lol. OP didn't say what their motivation was.
edit: nvm, in other comments OP has said they're concerned about an xz style of backdoor. In any case, I would still be interested to read about someone trying what OP is suggesting.
Building an Android ROM is decently resource-intensive. Back when DivestOS was first discontinued, I wanted to see if there was anything I could do about rolling my own updates for my device. Decided against it once I saw how much RAM (or tradeoff being time) it would need.
Also I'm lazy and I'd probably miss security updates if I had to go through the build process as frequently as GrapheneOS updates.
Only the first build is so slow, the subsequent ones with new updates are a few minutes each.
Why? Dont use it if your worried about a backdoor and how would building it from scratch stop the backdoor unless your going over all the source code yourself.
I'm assuming GrapheneOS isn't backdoored. If a new release were backdoored, I would have a non-zero chance to catch it while reviewing commit diffs, but the chance of catching it would be zero if I instead used auto-update and let the devs push whatever signed binary they wanted.
I've only built and ran their emulator. But, The first build will take a lot of time but subsequent builds are fast.
Keep in mind Google is not releasing source code regularly like they used to. And GrapheneOS has a OEM partner from them they get latest source code but not allowed to release for some time so build will not have latest updates
I haven't but I did built relatively large projects before (e.g. browsers) and basically it depends mostly on 2 things :
- are you in rush? If not just let it run over night, if you are then delegate it (if you can afford it and matches your threat model) to a cloud provider (rent a couple of instances for however long you need, that's where the hourly pricing matters)
- is the build system properly setup for reproducibility, e.g runs in a single container on AMD64? if so just start it and move on, otherwise be prepared for an indefinite amount of tinkering
I think it's interesting to do but honestly as someone else mentioned, builds are signed. In fact at the end of https://grapheneos.org/install/web#verified-boot-key-hash you get the verified boot hash. The goal is precisely to check that you actually get what you are supposed to have running. Basically the big picture of reproducible builds is that you do NOT have to do it and can STILL verify that you have exactly, up to a single bit, what should have.
The fact that devs sign the builds doesn't protect you from a Jia Tan type of actor. Jia Tan had social-engineered they way to a maintainer and then dropped their backdoor in the .tar releases. If you had compiled from the tree you couldn't be affected. It's possible to fail to review malicious commits even in this case, but it is still more transparent than pre-packaged releases. And there's no point to reproducible builds if no one actually reproduces them.
a Jia Tan type of actor
Yes, absolutely, yet the fact that we even know who they are proves that it's definitely an odd case. It's important to remember it but it's definitely not a normal situation.
You don't know anything about the lead developer.
It's not really necessary since the builds are signed