grapheneos
Joined 4 months ago
Karma
1,394
Submissions
603
Member since
Jun 18
Recent submissions
Comment · 1 day ago
Comment · 1 day ago
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Comment · 1 day ago
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Comment · 1 day ago
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Comment · 1 day ago
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Comment · 1 day ago
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Comment · 4 days ago
It's ludicrous to claim software with signed releases isn't open source. Having private keys used to generate the signatures for APKs, updates and the vbmeta image doesn't somehow make it not open source. Every APK is signed and the software isn't somehow not open source because the signature requires the private keys. There are standard tools to compare APKs with different signing keys to ensure the build is reproducible and the same thing exists for the OS as a whole which contains many signed APKs and a signed vbmeta image with verified boot metadata.
The signatures enable the update client to verify the releases and the firmware to verify the OS with the public key flashed by the user as part of installing the OS. Signed updates and verified boot fully work with any build of GrapheneOS following our build instructions. Auditor and AttestationServer also work once they're rebuilt with the new verified boot hash included.
Comment · 5 days ago
Software doesn't stop being open source because the releases are signed to be able to verify those. Any OS can be installed on the supported device. The verified boot key hash shown at boot will be different for an unofficial build and so will a query to the hardware asking it to provide it. Auditor and AttestationServer are open source. Those work fine with unofficial builds and forks of GrapheneOS after making builds of those with the correct key.
Comment · 5 days ago
GrapheneOS is open source with reproducible builds. Android key attestation isn't specific to GrapheneOS and is OS independent. It mainly exists to check that a key was generated in a hardware keystore. There's no pass or fail based on having an official or unofficial build of GrapheneOS. The hardware can sign public key certificates with metadata on device security including verified boot state (green, yellow or orange), verified boot key hash, verified boot hash (hash of the core OS) and patch levels. That's not nefarious and is useful to end users. Our Auditor app uses it to help users protect their devices. GrapheneOS doesn't use it to require people to use an official build for any purpose. Some banks have regulations requiring them to verify the hardware, OS and app which means they need to specifically allow each non-Google-certified OS. There are only around 3 banking apps are known to permit GrapheneOS that way and without it they'd ban using any non-Google-certified OS.
Comment · 7 days ago
LineageOS doesn't keep up with very important standard privacy/security patches and protections. This post is a clear example where it took until October 2026 to ship crucial privacy/security patches and protections from June 2026.
GrapheneOS greatly improves upon the increasingly inadequate privacy and security provided by Android. It fixes many privacy and security vulnerabilities along with adding important missing privacy and security protections.
Traditional cell phones lack any form of secure communication and are entirely dependent on cellular. Those lack basic updates and security protections in practice too. Those are the opposite of a more private and secure device. A smartphone with GrapheneOS or iOS is far more private and secure than any traditional desktop/laptop computer at a hardware, firmware and software level.
There's nothing illegal about using GrapheneOS.
Comment · 7 days ago
There will be both the option to install GrapheneOS on a device sold without it and to buy a device with it preinstalled. Devices sold with it preinstalled are coming after the initial launch of support. Details cannot be provided yet.
Comment · 7 days ago
Permissively licensed open source code is open source code. Firmware on a secure element can be open source without it being possible to replace it without the signing key on a production device.
German courts are not bound by precedent in the same way as US courts and you're referring to a specific case in Germany which cannot be broadly applied.
AOSP ships a lot of GPLv2 code (Linux kernel and OpenJDK libraries among other components) but doesn't use GPLv3 for multiple reasons.
AOSP used to use a lot of GPLv3 code as part of the toolchain for building AOSP but that was replaced with LLVM, ToyBox and other permissively licensed projects.
Comment · 7 days ago
We try to convince them not to do it at all, but if they insist on doing it then we point them to our signed list of verified boot key fingerprints and Google's library for key attestation verification. We have a page with a guide on allowing GrapheneOS this way for apps using the Play Integrity API. We keep a list of a small subset of apps using the Play Integrity API to ban GrapheneOS there for users to pressure them to allow GrapheneOS too. We definitely don't encourage adopting it for apps not using the Play Integrity API already but rather it's a compromise to get support for the official releases of GrapheneOS and other operating systems with verified boot and the app sandbox intact for apps otherwise banning them.
Comment · 7 days ago
Yes, we very actively engaged in discussion with the EU Commission. It hasn't resulted in any major actions against Google in this area yet. The people we've talked to seem to understand what we've told them but it's not more broadly understood. They focus on easier to understand and less technical things where Google can't fool them with misleading claims and misdirection as easily such as forcing them to allow alternatives to the Play Store and Google AI.
Play Integrity API is disguised as a security feature and is aligned with governments wanting to crack down on people freely using arbitrary software and hardware which makes it hard to convince governments to stop it.
Android's public issue tracker isn't the real issue tracker. They create internal issues for what's reported there. That means the discussion about it doesn't happen there. Security bug reports are mainly treated as a request for a bounty and little communication happens beyond what's related to receiving a bounty for it. If someone else filed it then it gets closed and no further info is provided. If someone external filed the first report, they hardly get any updates themselves beyond eventually being informed which Android Security Bulletin included it months after it was disclosed to OEMs and allowed to be patched.