I'm wondering what would be necessary to build GrapheneOS releases yourself, and regularly update your phone from your own servers, with your builds. The server for apps.grapheneos.org should also be replaced. Has anyone done this?

The documentation for GrapheneOS has a section about how to reproduce builds:

https://grapheneos.org/build#reproducible-builds

But it would be more involved than that.

It's not really necessary since the builds are signed

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

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.

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.

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.

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.

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.

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.

You don't know anything about the lead developer.

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.