GrapheneOSWe have early access to Android Security Bulletin patches and will be able to set up a workflow where we can have releases already built and tested prior to the embargo ending. For now, we've still been doing the builds after the embargo ends. It will mainly help when they screw up pushing to AOSP.
We're in the process of obtaining early access to the major quarterly and yearly releases. This is a much bigger deal and will substantially help us. There's an immense workload with a lot of time pressure for porting to new major releases without early access which gets worse the more we change.
We did not have early access to Android 16 QPR1 and have not been able to start porting yet. We should have early access prior to Android 16 QPR2.
We're going to need to make private repositories for working on this stuff internally. We can potentially make special preview releases based on these.
Google recently made incredibly misguided changes to Android security updates. Android security patches are almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
We can't break the embargo ourselves but if someone posted the patches publicly we would be able to ship them months early, as would others. The patches are broadly distributed to OEMs where most of their engineers have access. Companies like NSO can easily obtain access. It's not a safe system.
Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins. This is harming Android security to make OEMs look better by lowering the bar.
The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. Google has also abandoned pretending it's private by allowing binary-only embargo breaches.
Android's management has clearly overruled the concerns of their security team and chosen to significantly harm Android security for marketing reasons. Lowering the bar for OEMs to pretend things are fine while reducing security for everyone is a ridiculous approach and should be quickly reversed.
Android is very understaffed due to layoffs/buyouts and insufficient hiring. This is impacting Linux kernel and Android security. Google hasn't fixed https://taptrap.click/ which is a serious issue privately disclosed to them in October 2024. We were informed in June 2025 and it took us a few hours to fix...
Google does a massive portion of the security work on the Linux kernel, LLVM and other projects including implementing exploit protections, bug finding tools and doing fuzzing. They're providing the resources and infrastructure for Linux kernel LTS releases. Others aren't stepping up to the plate.
We don't expect there to be much pushback against this via tech media despite how obscene it is to provide 4 months of patch access to sophisticated attackers. They can easily get it from OEMs or even make an OEM. Whistleblowers should publicly post the signed zips since attackers have it already.
Security patch backports were pushed to the Android Open Source Project on September 2nd but it wasn't done properly. Android 16 QPR1 was also supposed to be pushed to the AOSP on September 3rd and it was even confirmed they'd still be doing that but it hasn't happened. Perhaps too many layoffs...
Even if no whistleblowers leak the signed zips we can still bring this system down ourselves without breaking any embargo. Our plan is to make special releases with the patches which are otherwise identical to our regular releases. External developers can reverse it from that for regular GrapheneOS.
We're allowed to make a release with currently available revision of the December 2025 Android security patches right now but we wouldn't be allowed to publish sources. Therefore, we'd need to do this separately from regular GrapheneOS. We could special release channels for it with delayed tags...
It's trivial for someone to reverse the Java and Kotlin patches to source code within an hour of us releasing that. They could then submit security patches elsewhere including to GrapheneOS. This clearly isn't something Google's technical security people came up with as it's completety nonsensical.
fractal_timescales@GrapheneOS So just to check my understanding here, you'd make a special release, binaries only for the patches. Someone outside the project decompiles the binary, uses it to discover the vulnerability, which they then report to you. Then you fix it for regular Graphene users.
If I'm understanding correctly, then is there a chance the regular Graphene users don't get the patches if nobody outside the project does the decompiling? I would love to contribute, and maybe this is a reason to get good at doing this kind of thing. But I don't think my technical skills are up to scratch yet.
@fractal_timescales Users of the regular GrapheneOS would still get the updates when most Android users do once the embargo ends. Also, if someone leaks the patches publicly, then the embargo is dead as we can use what was leaked publicly. If people don't like this and work at an Android OEM they can just publicly post the signed zip.
@GrapheneOS Yes sorry should have clarified, I meant regular Graphene users wouldn't get them until the embargo ends if no one does the decompiling.
astroboy@GrapheneOS @fractal_timescales Don't you get banned if you leak the source code like this? Will you lose access to the security bulletin?
@astroboy @fractal_timescales Their 3-4 month embargo has an explicit exception for binary-only releases of patches. We're fully permitted to release the December 2025 patches this month in a release but not the source code. Therefore, we can only do it if we make new release channels for obtaining early releases of patches with source code and description still under embargo. We're allowed to publish a release with the patches and we're even allowed to list all the CVEs for Dec 2025 it fixes.
Buccia@GrapheneOS What's the point of scheduling patches so far into the future? If they are made aware of the vulnerabilities now, why not scheduling them on the next month?
@BucciaBuccia Their previous system was disclosing patches to OEMs 1 month before the coordinated disclosure date. This was Android's monthly security backport system. We considered 1 month to be far too long for so broadly disclosing the patches. Android has now moved to doing the same thing around 4 months ahead instead of 1. They're aware that it's a completely broken system to an extent and have therefore allowed binary-only releases as a compromise to try to squash OEM complaints...
@BucciaBuccia Nearly all OEMs were failing to ship the monthly security patch backports despite how straightforward it is. The backports alone are not even particularly complete patches. They're only the High and Critical severity Android patches and a small subset of external patches for the Linux kernel, etc. Getting the full Android patches requires the latest stable releases.
They changed the system to make OEMs look better. It's due to pressure from some OEMs and Google marketing Android.
CerebrosuS@GrapheneOS so where to find the patches?
@cerebrosus We're in the process of making a system for providing separate release channels with binary-only patches for December 2025. It should be ready within a few days. We haven't published released with it yet but we're allowed to, we just have to finish dealing with it. Not all of the patches are applying cleanly to android-16.0.0_r1 and we need to figure that out first.