| 9 Nov 2025 |
 puffnfresh | and that's why the PR includes support for 4096 keys - that's what I'm using | 07:22:28 |
| puffnfresh | I haven't tested Robotnix's key generation since my first attempt at signing, so gmscompat_lib being missing would probably be a problem | 07:23:25 |
 pentane | Okay it seems like we're talking about two different things | 09:53:58 |
| pentane | this error message refers to the payload private key of the APEX in question | 09:57:12 |
| pentane | the test-keys variant of that payload private key is present in the GrapheneOS source tree (see https://github.com/GrapheneOS/platform_packages_modules_Virtualization/tree/16/build/apex), but not in the otaTools derivation which releaseScript cds into | 09:59:45 |
| pentane | okay, scratch that. so I investigated this, and it seems like the otatools AOSP build target (i.e. otatools.zip in the config.build.android version) erroneously doesn't include the APEX payload test keys | 10:05:23 |
| pentane | so that was the reason for why you were getting these error messages | 10:05:33 |
| pentane | I don't see rn though why there should be a guarantee that this happens consistently (for instance, looking into the otaTools derivation, the APEX container test keys are there, and likewise for the normal APK signing keys) | 10:06:47 |
| pentane | if you're interested - I'm currently experimenting with patching sign_target_files_apks to throw error messages if one of the test keys hasn't been replaced. Don't think we should do that in production though, I'd probably write a small validation program in Rust that takes META/apkcerts.txt and META/apexkeys.txt, and the signTargetFilesArgs from target_files.zip as an option to check whether the args exhaustively cover all the keys | 10:09:06 |
