GrapheneOS version 2024101801 released:
https://grapheneos.org/releases#2024101801
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/16564-grapheneos-version-2024101801-released
#GrapheneOS #privacy #security
@GrapheneOS may I ask if Play Integrity is working properly yet? (Mainly for things like banking apps)
If not, since this has been brought up, Google should be held liable for holding a monopoly over Android competition.
Want GMS? Gotta go through Google (as a company only) enter a license agreement (contract) and then still not be fully allowed to do what you wanted in the first place.
Don’t pass strong integrity? No apps like Step banking work.
Want to make your own ROM? Can’t have GMS unless you do as I said above.
Wanna use Google specific features of absolutely any kind? GMS needed.
I would specifically like to request that GrapheneOS do what DivestOS does, and provide a flashable pkmd/bin avb key to be flashed to the avb_custom_key partition to the devices that support it. An example would be the Pixel 6a
> may I ask if Play Integrity is working properly yet?
It has always worked properly. GrapheneOS is not certified by Google which is required for certain parts to pass.
> No apps like Step banking work.
This is a choice by a small number of apps to ban using an alternate OS. There is a way for them to permit GrapheneOS.
> Want to make your own ROM?
It’s an OS, not a ROM.
> I would specifically like to request that GrapheneOS do what DivestOS does
This is totally wrong.
@daedaevibin GrapheneOS has always used verified boot as long as it has been available. Why do you think we don’t use verified boot? It’s clearly listed in our hardware requirements:
https://grapheneos.org/faq#future-devices
We substantially improve the implementation rather than greatly reducing it through the LineageOS changes that are in DivestOS. It doesn’t change that none of these is certified by Google. Some of our improvements to verified boot are included on our features page:
@daedaevibin The Pixel firmware and driver patches depend on Android 15 since it was released on October 15. Additionally, the full Android privacy and security devices across devices now require Android 15. Only a subset of the patches are backported to older Android releases. If you’re using DivestOS on a Pixel, you’re not getting current privacy/security patches. It’s also a much less hardened OS than GrapheneOS with only a subset of the privacy and security features ported to LineageOS.
@[email protected] DivestOS does what they can to undo the reduction of privacy and security caused by LineageOS, which they use for broad device support rather than because it’s a good base for a private or secure OS. DivestOS themselves recommends using GrapheneOS if you can afford a device supporting it. Anyway, it’s very strange that you would think GrapheneOS was the first alternate OS using it. We’ve made substantial improvements to verified boot over the standard Android implementation…
@[email protected] It’s not clear where you get the idea that we don’t use verified boot. That’s clearly contradicted across our documentation. If you look at https://grapheneos.org/install/web, https://grapheneos.org/install/cli, https://grapheneos.org/features, etc. you can clearly see we don’t only use verified boot but significantly improve it over the standard Android implementation. We also provide our Auditor app using the secure element for hardware attestation using per-pairing attestation signing keys.
@GrapheneOS yes, I’m aware of the security and outdated releases of DivestOS. I was simply using it to make relations to what I was saying. They are severely outdated, only having A13 for bluejay.
I would like to request a bit more customization options though, such as fonts or icons designs etc. maybe have a look at EvoX if you really really want to get into the specifics?
I was simply wondering why GrapheneOS didn’t provide a ***pkmd.bin file as well, unlike DivestOS does. It seems to be a more efficient way to get it into the system for verification properly instead of other methods I’ve seen. Maybe there’s something done differently?
> I was simply wondering why GrapheneOS didn’t provide a ***pkmd.bin file as well
This is wrong and it’s not clear where you get the idea that we don’t use it. We were the first alternate OS using verified boot and DivestOS implemented it based on our documentation and scripts. We were the ones to reverse engineer the firmware, discover the avb_custom_key support and submitted the documentation to AOSP for it.
> avb_custom_key partition
It is not a partition.
> It seems to be a more efficient way to get it into the system for verification properly instead of other methods I’ve seen.
There is no other way to flash a key to the secure element for verified boot. That is how verified boot is implemented for an alternate OS. Both of our install processes flash the verified boot public key after flashing the OS. We were the first ones to ever use this functionality before they had official documentation, and we made the initial AOSP docs.
@GrapheneOS ah, got it. I see, like everything else since you don’t seem to provide direct downloads you just have it all flashed at one time through the web interface (or whatever is being used). Right?
@GrapheneOS then what is it if it’s not a partition? It does exist on the pixel 6a/bluejay, and you can flash pkmd.bin files to it. Whenever you do so, or do it incorrectly, etc, fastboot calls it a partition. I guess I must be missing a lot of information somewhere, but all the same, would love to see GrapheneOS develop further and be properly allowed to pass play integrity API.
@daedaevibin It’s not a partition. It gets flashed to the secure element via an API provided by the secure element. The fastboot firmware implemented support for flashing it via the image flashing interface. There’s also not actually a bootloader partition but rather those are containers with images nested inside. There a whole bunch of boot firmware images flashed to separate partitions from bootloader.img. An over-the-air update has them as separate images, not bundled into the bootloader.img.
