GrapheneOS security preview releases

NetRunner88

de0u

Vuraze I was told that the embargo may end soon if someone was able to reverse engineer the security patches and release it with the source code, effectively showing Google how silly this whole thing is. Is that true, and has anyone done that yet?

If that had already happened, then the post from the project account which began this thread would not have been necessary.

As for what Google might do if people are energetic enough about reverse engineering, that can be discovered only if somebody does.

GrapheneOS

Vuraze If people reverse engineer exactly what a patch does and publicly post about it, then that's public information not under an embargo. If people write a patch to fix it, that can be included.

We already fixed one issue in the regular releases because a patch was publicly available elsewhere. We plan to do more of that by checking the external projects.

ryrona

GrapheneOS Our plan is to publish what we used once the embargo ends, so it will still be open source, but delayed.

Does this mean it will be published in such a way that the release can be reproduced, like regular reproducible builds? Because being able to confirm the binary release corresponds to source code 3 months late is still way way better than not being able to confirm it at all.

GrapheneOS If people reverse engineer exactly what a patch does and publicly post about it, then that's public information not under an embargo. If people write a patch to fix it, that can be included.

I tried asking a few times in the alpha testing channel on Matrix, but I try here too:

Are we legally permitted to reverse engineer the OS images containing the embargoed patches? Ie are you legally allowed to allow reverse engineering of the OS images containing the embargoed patches, or the license terms for the embargoed patches that prohibit you from publishing them in source form also forces you to prohibit reverse engineering the binary releases of them?

Are you able to provide the exact terms you have been granted access to the embargoed patches under and are able to publish them in binary form under? So we can verify the legality if reverse engineering them, both for our own sake, and for GrapheneOS sake? Or are the terms also under NDA?

de0u

Panda-na One question though. With all of these longer embargoes, fewer people will be able to review the code.

Because code that to fix a vulnerability replaces a truly tiny fraction of the code base, the vast majorit of the code is continuously as reviewable as it ever was. Code that is temporarily non-generally-reviewable during each embargo period will be reviewable after the embargo is over. The net decrease in reviewability is tiny.

Panda-na Can this be an easier way for Google to implement anti-privacy practices in Android?

How?

Panda-na And also, is this maybe some sort of way to help law enforcement break into Android phones, since problably most Android phones out there (even new flagships) is not updated with the newest CVE's, but maybe Cellebrite can get a hold of the patches? Making their work substantially easier?

Cellebrite can already get into the vast majority of phones. It is genuinely quite likely that they are capable of analyzing binaries, especially since they seem to be pretty good at breaking into WhatsApp.

de0u

Panda-na Are you checking the code of these CVE's to ensure that it is in our best interest? Maybe I'm completely wrong here, if so, I'm sorry, I'm just curious.

I am having trouble following this line of questioning.

It is already the case that the GrapheneOS team ships firmware updates from Google for the cellular modem, Wi-Fi, Bluetooth, and the GPU. The firmware is in binary form. I don't expect the GrapheneOS team is frequently decompiling the firmware to determine what is being changed between releases.
Before the current "security preview" setup, the GrapheneOS team has been shipping truly gigantic amounts of AOSP code from Google, with truly sweeping changes in at least the quarterly updates. They have been taking some amount of care with this, but clearly not infinite care, because both Google and various external security researchers keep finding bugs that the GrapheneOS team hasn't found.

Given that imperfect situation, meaning a mixture of difficult-to-inspect binary blobs and impossible-to-fully-inspect source code, it's not clear why the new situation would present significant new concerns. Some of the "security preview" fixes will be in binary blobs, and some of them will be in source code. The ones that are in source code will be publicly disclosed at the end of each embargo period.

Honestly perhaps the biggest threat posed to GrapheneOS users by the new scheme is that the GrapheneOS team will be maintaining two versions of the OS at the same time, which plausibly will stretch the development team thinner.

Please note that I do not speak for the GrapheneOS project.

de0u

ryrona Are we legally permitted to reverse engineer the OS images containing the embargoed patches?

I think that may be a question for an attorney. For example, I believe I have heard that EU residents have reverse engineering rights that U.S. residents do not.

GrapheneOS

ryrona

Does this mean it will be published in such a way that the release can be reproduced, like regular reproducible builds? Because being able to confirm the binary release corresponds to source code 3 months late is still way way better than not being able to confirm it at all.

Yes, it will be possible to reproduce the builds after the fact as can be done with the regular releases at launch. We've implemented the security preview releases by using the same sources we used for the regular releases and running a script which applies patches we've saved in a repository for the preview patches with the conflicts resolved by us in advance and a script to apply them. It also patches it into being a security preview release by renaming the channel metadata. We're tagging the security preview releases in this repository, so we can make a public variant of the repository where we push the same stuff once the embargo ends.

Are we legally permitted to reverse engineer the OS images containing the embargoed patches? Ie are you legally allowed to allow reverse engineering of the OS images containing the embargoed patches, or the license terms for the embargoed patches that prohibit you from publishing them in source form also forces you to prohibit reverse engineering the binary releases of them?

These patches are under the Apache 2 license and other permissive licenses. We're not allowed to publish them until the embargo ends due to the required NDA. We're restricted by NDA, not software licensing. There's no special license applied to the preview patches. It's open source code but shipped under an NDA disallowing publishing it before Google does.

Are you able to provide the exact terms you have been granted access to the embargoed patches under and are able to publish them in binary form under? So we can verify the legality if reverse engineering them, both for our own sake, and for GrapheneOS sake? Or are the terms also under NDA?

The terms with our OEM partner are not really under NDA, and neither is which OEM we're working with, but we don't want to publish which OEM we're working with until an official announcement with them. We'd also prefer if they make the announcement and we spread it because it would look better.

dhhdjbd

I think this should be a pinned post please?

and i am wondering if default off is the correct approach / or if there is some option like a notification to inform users about this, considering 3 month late patches at worst seem significant

mmobder

dhhdjbd if default off is the correct approach

I second this - if GOS is about security, what's the negative impact on having it as an opt-out? Is it the frequency of releases, app optimizations, ...?

ryrona

de0u I think that may be a question for an attorney. For example, I believe I have heard that EU residents have reverse engineering rights that U.S. residents do not.

No, I do not have the capability to involve an attorney, and I am not interested in if there is rights I have that override contracts or license terms.

I am asking: What license is the GrapheneOS builds with the embargoed patches released under? Eg, if one of the patches were for a GPL-2 licensed component, those patches would also automatically be GPL-2 licensed, and reverse engineering them is expressively allowed, in fact, the publisher would have to give the patches to me. GrapheneOS account already confirmed no patch is for GPL-2 licensed code. If one of the patches is for a Apache-2.0 licensed component, the same is not true. If the component is purely compiled from Apache-2.0 licensed code, the binary is also licensed that way, but if some of the code is proprietary, so might the binary be.

So I am asking, what license are the patches provided as? Proprietary? What license does the binaries have? Proprietary? Who owns the proprietary code and thus binaries? Google? In that case, under what license terms are the patches or binaries provided? Same as stock OS builds? Special license for builds with embargoed code?

Upstate1618

Once we have early access to qpr, can we get an OS release earlier than aosp source release? Can we also get monthly aisp release?

raccoondad

GrapheneOS your commitment to user choice and open source software is not overlooked, thank you GOS!

GrapheneOS

ryrona The only GPL2 projects are external ones so we could use the upstream patches instead, which we already switched to doing for one of the patches and can potentially do for a few more. It's possible Android could share patches still not disclosed by external projects but it doesn't really happen in practice for GPLv2 code since there's hardly any of it beyond the Java standard libraries. The Linux kernel is out-of-scope for these patch previews since the kernel drivers are vendor patches and mainline patches are already public when they're included as things which must be fixed. The mainline patches are really meant to come from updating the LTS revision and Android has been moving towards requiring LTS revision updates but very slowly.

ryrona

GrapheneOS We're restricted by NDA, not software licensing. There's no special license applied to the preview patches. It's open source code but shipped under an NDA disallowing publishing it before Google does.

Okay. Thank you. That answers my question. I didn't sign any NDA, so the NDA doesn't apply to me. And Apache-2 license requires that any derivative work that is of different license terms must have this fact prominently displayed, which does not appear to be the case, so the compiled binaries are purely Apache-2 or other permissively licensed code, which expressively allows anyone to reproduce the work in source or binary form, which means reverse engineering is expressively permitted :)

linuxaki88

GrapheneOS
So GrapheneOS team can audit the code to see if something is "suspicious" and then implement it and forward it to security preview realeses! I'm saying that because of previous comments suggest that google can include some "spy" code!

ttmp12

GrapheneOS Yes, it will be possible to reproduce the builds after the fact as can be done with the regular releases at launch. We've implemented the security preview releases by using the same sources we used for the regular releases and running a script which applies patches we've saved in a repository for the preview patches with the conflicts resolved by us in advance and a script to apply them. It also patches it into being a security preview release by renaming the channel metadata. We're tagging the security preview releases in this repository, so we can make a public variant of the repository where we push the same stuff once the embargo ends.

This information is much appreciated! I had the same question. This should be added to the initial post.

yore

mmmm I understand you want to talk about it.

But I find GrapheneOS is usually quite transparent with things. So my understanding is if they chose to announce they have an OEM but not who, there's probably good reason for it.

Here's a quote from the project account:

GrapheneOS The terms with our OEM partner are not really under NDA, and neither is which OEM we're working with, but we don't want to publish which OEM we're working with until an official announcement with them. We'd also prefer if they make the announcement and we spread it because it would look better.

That is why I personally prefer not to speculate about it. It's probably best we wait it out until the project or the OEM releases any further information.

architekt

GrapheneOS (...) We recommend enabling this.

(...) You can enable security preview releases via Settings > System > System update > Receive security preview releases

I'm on the most recent (stable) version but don't see that option?

de0u

architekt I'm on the most recent (stable) version but don't see that option?

What is the build number of the release on the device? That is the most reliable way to know whether or not a device is running the most recent version.

architekt

de0u my bad I missed an update as it seems the previous install failed, after rebooting the option is now available

ElliesSurviving

linuxaki88 google wouldn't be able to do that, the patches are given in source to GrapheneOS who build binary patches to be installed on devices where its been enabled, the code just cannot be released to the public as of now

workeronthewalls

ElliesSurviving Then how can you tell that the apparently more secure version of GrapheneOS with the latest security patches that is not open source for the end user because of that embargo, isn't an intelligence agency putting a backdoor in it? That's the point of it being open source, so you can look for yourself and verify.