GrapheneOS security preview releases

tietoturva

Would it be possible to let external auditor check that the security preview release is indeed built based on the private reposity? This should not conflict with the embargo, but would be a key factor to build trust in this new situation. Preferably, active community would just release the patches by extracting from source code and Google would make changes to the embargo..

GrapheneOS

tietoturva It's possible, but would require having someone trustworthy to do it that's willing to sign an NDA and has the necessary skill set to compare the builds properly. There's a community member reproducing the regular releases but it's a lot of work to keep it up-to-date including dealing with filtering out the signatures and other metadata tied to a specific set of signing keys, etc. There are also sometimes false positives for other reasons and there can be differences caused by upstream reproducibility regressions. There are some rare latent issues which can occur causing minor differences. It's important that someone comparing this is able to filter out the noise (i.e. things which aren't actually differences in code or data but rather signatures, etc.) and determine the actual cause of any actual differences, otherwise it's counterproductive.

de0u

tietoturva Would it be possible to let external auditor check that the security preview release is indeed built based on the private reposity?

In a mathematical sense, of course.

tietoturva This should not conflict with the embargo, but would be a key factor to build trust in this new situation.

I assume the cost would be $100,000 per year or more (probably more).

Meanwhile, if the idea is protecting against hypothetical shadowy forces hypothetically coercing the GrapheneOS project into shipping compiled code that hypothetically wouldn't match the source code, presumably in order to ship hypothetical back doors... what would stop the hypothetical shadowy forces from hypothetically coercing the external auditor as well?

tietoturva

de0u

I did not mention any shadowy forces, but instead a way to support the open source status of the code. The team refers to it as delayed open source while it is closed code until published as open source. I do not have a solution on who could take on this task and at what cost would it come. Anyway, it would be a more transparent approach. For example, academic work is peer reviewed, as in externally audited, and this would be somewhat similar.

GrapheneOS

tietoturva The patches are made by Google and shared with every Android OEM with partner access. They're not in any way GrapheneOS specific patches. We're reviewing and applying the the patches. We have 2 developers working on it together.

dhhdjbd

qpwoei trusting the security or preview who is made by somebody else and can't be verified by nobady

i dont think this is how it works,
i think grapehenOs team gets the source code for the security releases, but is only allowed to publish them as binary releases

Edit:

GrapheneOS The patches are made by Google and shared with every Android OEM with partner access. They're not in any way GrapheneOS specific patches. We're reviewing and applying the the patches. We have 2 developers working on it together.

sh4tr0x

GrapheneOS

Google released a second Update in October, Pixels 7 to 10.
But they don't say what changed.

Maybe it has something to do with their new "Risk based" policies?

indigomadelin

Why do we see patches for CVE-2022 and CVE-2026? Does this imply that sometimes it takes Google 3 years to patch vulnerabilities? Why are some dated 2026?

GrapheneOS

indigomadelin The dates don't mean very much. They tend to take around 90 days to fix an issue reported externally. The backlog of internally found issues includes endless bugs found by fuzzers, etc. and the date may refer to when it was first found, not when it was determined it was a vulnerability. You can see the dates don't mean much based on the fact that there are 2026 ones assigned already for a portion of the ones scheduled to be patched in 2026 bulletins (mainly March 2026) which we already have for the security preview releases.

« Previous Page