GrapheneOS accessed Android security patches but not allowed to publish sources
24 comments
·September 11, 2025LinAGKar
lima
The stupidest part is that, according to the thread, OEMs are allowed to provide binary only patches before the embargo ends, making the whole thing nonsensical since it's trivial to figure out the vulnerabilities from the binaries.
Fun fact: Google actually owns the most commonly used tool, BinDiff ;)
nroets
Unless the OEMs bundle numerous changes with the security patch(es).
(I'm not saying it happens. I just theorise how the policy could have been envisaged)
tester89
How does this work legally? If Android AOSP is open-source, once one OEM updates, surely the owner gets the legal right to request sources. IIRC the maximum delay is 30 days.
bri3d
Almost all of AOSP is under the Apache or BSD licenses, not the GPL. Very few GPL components remain (the kernel being the large and obvious one).
So, yes, making a GPL request will work for the very few components still under GPL, if a vendor releases a binary patch. But for most things outside of the kernel, patch diffing comes back into play, just like on every closed-source OS.
Hizonner
Fuck, and I cannot emphasize this enough, the OEMs.
I am so sick of security being compromised so stupid, lazy people don't have to do their jobs efficiently. Not like this is even unusual.
Zigurd
Welcome to Android. It started out a bit undercooked and Google relied on OEMs to make finished polished products. Then the reality that OEMs suck at software hit them in the face. They spent years acquiring more control of their platform while trying not to piss off Samsung.
stebalien
The bigger headline is that Google is effectively giving attackers 3-4 months of advanced access to security patches: https://grapheneos.social/@GrapheneOS/115164183840111564.
goku12
Have you considered the possibility that this may not be motivated by security at all, given the recent spate of similarly illogical and somewhat hostile decisions?
stebalien
The solution (heavily) alluded to by GrapheneOS in https://grapheneos.social/@GrapheneOS/115164212472627210 and https://grapheneos.social/@GrapheneOS/115165250870239451 is:
1. Release binary-only updates (opt-in). 2. Let the community (a) make GPL source requests for any GPLed components and (b) let the community reverse engineer the vulnerabilities from the binary updates. 3. Publish the source once everything is public anyways.
Which just shows how utterly ridiculous all this is.
transpute
Related discussion earlier this week, https://news.ycombinator.com/item?id=45158523
mcflubbins
"They can easily get it from OEMs or even make an OEM."[0]
I agree with their points in the thread, but could Graphene "become" an OEM to get access to the security patches sooner? Just curious.
[0] https://grapheneos.social/@GrapheneOS/115164297480036952
evgpbfhnr
They have access to the patches.
They just can't make an official release with it, because they can't publish the patch sources (embargoed) and their releases being open-source must match what they published...
qingcharles
They have an OEM partner right now who funnels them the updates, which is how they get access to them.
null
honeybadger1
i don't understand googles rationale here, what is the point in giving wind to the hackers sails while also driving home the narrative that android is a less secure system, especially after the recent changes related to the security of the latest iphone?
Miaourt
You mean the changes Pixels phones had since late 2021 ? /s https://grapheneos.social/@GrapheneOS/115176133102237994
honeybadger1
we're talking about OEM devices aren't we?
g-b-r
If the smart plan of having others reverse-engineer the fixes won't work, I imagine they'll turn into a delayed-source product.
To my recollection, they always maintained that being open-source doesn't matter for security, after all
g-b-r
(I strongly disagree)
9cb14c1ec0
This is ridiculous. Makes one wonder about the state of OEM development. It's not hard to build a CI pipeline for android. There is no good reason OEMs can't be running test builds of ROMs with security patches within hours, and have QA done in a day or two, or a week max.
baby_souffle
> There is no good reason OEMs can't be running test builds of ROMs with security patches within hours
That sounds like it costs money and doesn’t net the mfg new sales.
all2
Trying to do software well at hardware centric companies is hard. Mostly for this reasoning.
pixl97
>Makes one wonder about the state of OEM development.
Why wonder at all, it sucks and it's security is generally in shambles. Security is rarely very high on their priorities as features/prettiness is what sells their phones.
So basically to summarize, Google embargoes security patches for four months so OEMs can push out updates more slowly. And if those patches were immediately added to an open source project like GrapheneOS, attackers would gain info on the vulnerabilities before OEMs provide updates (the GrapheneOS project can see the patches, but they can't ship them). But a lot of patches end up being leaked anyway, so the delay ends up being pointless.