by strcat | 2025-07-25 20:57:33+00:00
> GrapheneOS (like all modern AOSP based ROMS) can literally not function with just the open source code.

It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.

Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.

> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.

There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.

> Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.

I do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.

> 1. they are able to find a device they can run 100% open source code on with no binary blobs

There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.

A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.

> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.

It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.

> 3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly > 4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.

GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.