#GrapheneOS version 2024061400 was released. - revert upstream refactoring of the device association code in Android 14 QPR3 due to it introducing a chain crash bug at boot in edge cases with associated devices such as paired Android Wear devices - kernel (5.10): update to latest GKI LTS branch revision - Vanadium: update to version 126.0.6478.71.0

Releases | GrapheneOS

Pixel 6 and later use the open source Trusty OS for the Trusted Execution Environment (TrustZone) and secure core firmware. Starting with this month's quarterly release (Android 14 QPR3), Trusty sources and baseline applets are part of the Android Open Source Project in trusty/. Not everything is published, particularly Tensor specific portions. It'd be helpful to publish the rest to make it easier to audit and propose improvements. They still need to publish the Titan M2 fork of OpenTitan too, which they committed to eventually doing several years ago. The secure element in the Pixel 2 was an off-the-shelf NXP part running open source applets published in AOSP. In the Pixel 3, they moved to a custom secure element based on a standard ARM secure core and committed to open sourcing the firmware but it was blocked by the ARM NDA. OpenTitan was created to replace their secure elements based on ARM secure cores with a custom RISC-V design across their servers, Chromebooks and Pixel phones/tablets. Pixel 6 and later have a RISC-V secure element (Titan M2), but they still need to publish Pixel specific code. Upstream OpenTitan project is currently focused on implementing the TPM specification for desktop/server use. TPM is a horrible secure element API. It isn't what's used on Pixels where they got to design APIs for usage by the Android Open Source Project based on what it needs. This is closely related to publishing the rest of the Trusty code used for Pixels, since they implement communication using authenticated encryption between the SoC secure core and the standalone secure element. Non-Pixel Android ecosystem could benefit a lot from all this code.

Thank you for 1000 followers Nostr crew. Grateful to see so many fans of GrapheneOS here again. In the mean time, my profile picture was changed back to my old one. 🤔

We've found a serious bug in Android 14 QPR3 which can lead to devices getting stuck in a crash loop on boot after adding a device association such as a WearOS pairing. This impacts both stock Pixel OS and AOSP. Google is aware and reverted the broken change in Android 15 Beta 2. Today, we plan to do a release fixing this serious issue and the AOSP Bluetooth module regression breaking pairing with the Galaxy Watch6 device we purchased for testing due to previous Bluetooth regressions in Android 14 QPR2 breaking it. Today's release should reach Stable. If you don't depend on Bluetooth, you might as well update to the current OS release in the Beta channel and then switch back to Stable. Only reason it's not in the Stable channel yet is these 2 issues. There's another minor upstream Settings UI style issue which doesn't matter. #GrapheneOS

#GrapheneOS version 2024061300 released. I also missed the post about 2024061200 so I will go through both in brief. GrapheneOS moved to Android 14 QPR3 on the previous version. We've found at least one new issue with the Android Open Source Project 14 QPR3 Bluetooth module and are already working on resolving it. We'll have a quick follow-up release fixing the Bluetooth regression and other issues discovered during public Alpha testing. Pixel 8a is now supported as part of the standard Android releases instead of having a device branch based on Android 14 QPR1. We've had stable releases for it available since May 15th (1 day after launch) based on our last QPR1-based release (2024030300). Pixel 8a users will be getting the GrapheneOS improvements from March, April, May and June along with the Android 14 QPR2 and QPR3 improvements so it's a much larger release for the Pixel 8a. Changes since the 2024061200 release: - fix upstream Android 14 QPR3 regression which breaks updating certain apps with our app repository client - fix boot-time optimizing apps progress UI with Android 14 QPR3 and enable it again - fix regression in our Android 14 QPR3 port resulting in PIN scrambling in secondary users being determined by the Owner user setting - revert upstream Android 14 QPR3 Internet quick tile overhaul since it broke the functionality in secondary users - temporarily add back disabling memory tagging and hardened_malloc for surfaceflinger since Android 14 QPR3 didn't fix it as expected - disable temporary unconditional system crash notifications since we've gotten the initial feedback we needed via the previous release - add additional null check for eSIM wiping done as part of the duress PIN/password wipe implementation to avoid harmless exception - Settings: remove blank illustration from "Screen resolution" screen - Vanadium: update to version 126.0.6478.50.1 - make duress PIN/password tests faster and more reliable Changes since the 2024060500 release: - full 2024-06-05 security patch level rebased onto AP2A.240605.024 Android Open Source Project release, which is the 3rd quarterly maintenance/feature release for Android 14 (QPR3) - temporarily disable boot-time optimizing apps progress UI due to upstream Android 14 QPR3 regression (our own post-boot background optimizing apps progress notification works fine) - temporarily enable system crash notifications unconditionally for the initial QPR3-based release - change default USB-C port mode to "Charging-only when locked" from "Charging-only when locked, except before first unlock" - Settings: fix regression permitting disabling apps when it shouldn't be allowed due to device manager policy - Vanadium: update to version 126.0.6478.50.0 - GmsCompatConfig: update to version 117

Releases | GrapheneOS

#GrapheneOS version 2024060600 released. - Sandboxed Google Play compatibility layer: adjust to DynamiteLoader changes being deployed with a new feature flag in Play services 24.22 - stop treating pressing the spacebar on a physical keyboard as submitting the lockscreen password since it prevents entering passphrases with spaces (upstream Android bug which has existed for around 8.5 years) - Vanadium: update to version 125.0.6422.165.0 - GmsCompatConfig: update to version 116

Releases | GrapheneOS

#GrapheneOS version 2024060400 released. This is an early June security update release based on the May 2024 security patch backports since this month's release of the Android Open Source Project and stock Pixel OS with Android 14 QPR3 isn't available yet. There are also improvements to wiping which is used by the duress password. - full 2024-06-01 security patch level - extend the standard wipe-without-reboot implementation beyond wiping the hardware keystores (which prevents recovering any OS data by preventing deriving the key encryption keys) by also wiping the secdiscardable data needed to derive key encryption keys, the encrypted storage keys and the Weaver slots in the secure element through a secure element erase - kernel (5.10): update to latest GKI LTS branch revision - kernel (5.15): update to latest GKI LTS branch revision - kernel (6.1): update to latest GKI LTS branch revision

Releases | GrapheneOS

Latest release of #GrapheneOS finally shipped the long awaited duress PIN/password implementation. If you have a spare device, we recommend trying it out. We've added initial documentation to the features page:

Features overview | GrapheneOS

It near instantly wipes and shuts down. We've also finally added documentation on our USB-C port control to our features page:

Features overview | GrapheneOS

Most users can set this to "Charging-only when locked" without a loss of functionality or even "Charging-only" if you don't use USB accessories, DisplayPort or MTP. Default is "Charging-only when locked, except before first unlock" to avoid locking users out of devices with a broken touchscreen. The main threat model for this is defending the device until the auto-reboot timer started when the screen is locked gets user data back at rest.

#GrapheneOS version 2024053100 released. Duress Password is finally here. - add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down - disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it) - increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature - disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access - kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153 - kernel (6.1): update to latest GKI LTS branch revision - Vanadium: update to version 125.0.6422.147.0 - GmsCompatConfig: update to version 115 -make SystemUI tests compatible with GrapheneOS changes

Releases | GrapheneOS

The most recent release of #GrapheneOS (2024052100) adds the first piece of our ongoing work on duress/panic features. It makes standard factory resets including by device admin APIs wipe the device near instantly before it reboots to recovery to wipe and format it. We made our own wipe-without-reboot but we're backporting the Android 15 implementation instead of using ours. They made it in response to our vulnerability report about this (CVE-2024-29748, reported by GrapheneOS). The April release added 2 Pixel specific protections against the 2 vulnerabilities we reported, but both vulnerabilities essentially impact all Android devices and were only addressed for Pixels. The factory reset interruption also isn't fully addressed until they ship this part. A wipe without reboot is important as cutting device power during a restart can interrupt the wipe process. GrapheneOS now wipes without a reboot.

Releases | GrapheneOS