Mastodawn

Our roadmap for improving security of verifying updates is based on taking advantage of the reproducible builds. We plan to have multiple official build locations and a configurable signoff verification system in the update clients also usable with third party signoff providers.

Occasion_Antique Mar 6

https://github.com/GrapheneOS/script/commit/a7b69d9

Hi,

This is a new account, so I wasn’t sure where to ask this.

I noticed the NFC APK signing key was only recently added to the build scripts (a7b69d9). From what I understand, it was previously signed with the AOSP public test key.

Since those keys are publicly available, wouldn’t that be a security issue for a system component like NFC?

Was this communicated or i missed it, also to update ASAP?

https://github.com/GrapheneOS/grapheneos.org/commit/ecc26ba

Thanks.

add missing nfc signing key · GrapheneOS/script@a7b69d9

Scripting for generating signed production releases of AOSP and metadata for the Updater app along with partially automated maintenance of out-of-tree patch sets. - add missing nfc signing key · GrapheneOS/script@a7b69d9

GitHub

https://grapheneos.org/releases#2026021200

@Occasion_Antique GrapheneOS blocks system app updates not done via OS updates or App Store. Android has a recent protection which stops this from being a serious issue itself too.

Handling the changes adding new keys for signing components within APEX modules was included in the release notes for 2026021200 and documented on the build page:

> update release signing to handle AOSP APEX changes

We also made changes to prevent further added keys in AOSP regressing it.

GrapheneOS releases

Official releases of GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

GrapheneOS

Occasion_Antique Mar 6

Thanks for the clarification.

I was just worried after noticing the change.

You mentioned GrapheneOS blocks system app updates not done via OS updates or the App Store. Could you point to where this is enforced (code or docs)?

If someone got ADB access, would `adb install` still be blocked from updating a system component like the NFC APK?

A link would be helpful.

Thanks.

@Occasion_Antique Why would you be worried about this of all things that you could worry about? There are Critical and High severity issues being fixed on a regular basis. Why worry about a lightly privileged app?

> If someone got ADB access, would `adb install` still be blocked from updating a system component like the NFC APK?

No, but then they already have a lot more privileges than this app already. Android began blocking apps like this hijacking privileged permissions via shared UID.

https://github.com/GrapheneOS/platform_frameworks_base/commit/64789c4939e92f99a0c7a41c1d8165364cdfa35c

@Occasion_Antique

It's only possible to update system components via App Store or ADB.

Android doesn't have verified boot for system APK updates but rather that's a feature added by GrapheneOS, so it only weakened a protection we added rather than a standard one.

https://github.com/GrapheneOS/platform_frameworks_base/blob/8209fe0ab30eaf097c380bb373bc6433b29c3556/services/core/java/com/android/server/pm/InstallPackageHelper.java#L5041

This is a standard protection which prevents it from becoming far more privileged.

It was a minor issue and won't happen again when they quietly add more within-APEX APK keys again.

allow only first party app source and shell to update system packages · GrapheneOS/platform_frameworks_base@64789c4

Contribute to GrapheneOS/platform_frameworks_base development by creating an account on GitHub.

GitHub

Occasion_Antique Mar 6

Thanks, so its safe to use any recent builds right. I noticed the NFC key has been in AOSP for a while, More than 2 years.

Is there a reason this wasn’t handled earlier and only addressed recently? Even if its a minor issue.

@Occasion_Antique

This was never a practical issue. It's strange that you keep questioning whether releases are safe to use due to a minor issue which was present for a months and addressed a month ago.

We've been signing the NFC APEX with the main releasekey since it was introduced and it was still being properly signed. We didn't need to make a dedicated key for it until recently.

This only recently became an issue after Android 16. We now have detection for future AOSP key changes.

Occasion_Antique Mar 7

Since the NFC key has existed for a while, what changed in Android 16 that made this start being treated as an issue?

I’m curious about the technical reason for the delay in enforcing the dedicated key. Was this intentional, or was it simply missed until the changes in Android 16?

Reposted, as I see my messages are locked.

GrapheneOS Mar 7

@Occasion_Antique We were always signing the NFC APEX as long as it existed but there's an APK inside of the APEX which needs to be signed separately. We already explained why it happened due to an AOSP signing script deficiency not erroring out for having missing keys which is what we want it to do. We've addressed that so the issue can't happen again. We already had blocking of updating system apps without a first party source or ADB which along with an AOSP protection made this unimportant.

Occasion_Antique Mar 7

https://github.com/GrapheneOS/platform_build/commit/c70f942

I appreciate the precautions already in place to prevent such APKs from being installed accidentally. Was it mainly missed because the AOSP signing script didn’t error when the key was missing and the build completed successfully?

I noticed bluetooth was handled earlier and NFC was added in the next Android version, how was Bluetooth noticed but not NFC?

I'm not trying to raise an issue or controversy. I’m just trying to understand how it was missed.

add bluetooth to standard key mapping · GrapheneOS/platform_build@c70f942

Make Build System (being phased out upstream). Contribute to GrapheneOS/platform_build development by creating an account on GitHub.

GitHub