| 6 Nov 2025 |
 pentane ⭔ | which method did you use to get a list of all new APEX packages in android 16? looking into apkcerts.txt in the target files package, or something in these lines? | 21:49:17 |
| pentane ⭔ | bit of context: I'm a bit catious about declaring signing as "officially supported" again, since the AOSP sign_target_files_apks tool doesn't validate whether all APKs that were signed with the test keys during the main build have in fact been re-signed with the release ones. I'm considering writing some sort of validation script that looks at META/apkcerts.txt and META/apexkeys.txt in target_files.zip to validate whether the key mappings and APEX package names defined in the module systems cover everything that needs to be re-signed | 22:29:24 |
| 7 Nov 2025 |
 puffnfresh | the signing process complained when a key was missing, I just tried to sign, it would fail, I'd add that | 01:01:41 |
|  @emma:rory.gay left the room. | 22:44:02 |
| 8 Nov 2025 |
| pentane ⭔ | yeah, that's for keys that you specify with --extra-apks or --key-mapping that turn out to not exist on your filesystem | 21:45:57 |
| pentane ⭔ | but as far as I understand, sign_target_files_apks will happily leave the test keys in place if you don't specify that you wanna re-sign the APKs in question with release keys | 21:46:29 |
| pentane ⭔ | what were the exact error messages you were getting? | 22:18:57 |
| pentane ⭔ | also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16?) | 22:27:02 |
| pentane ⭔ | * also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16)? | 22:27:05 |
| pentane ⭔ | * also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key in your case (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16)? | 22:27:13 |
| 9 Nov 2025 |
| puffnfresh |
Error getting public key: b'Could not open file or uri for loading private key of public key from packages/modules/Virtualization/build/apex/com.android.virt.pem: No such file or directory\n'
| 04:41:44 |
| puffnfresh | at the time, I hadn't specified that as an extra-apk, and specifying it solved the problem - so I think it's opposite to what you're saying | 04:42:20 |
| puffnfresh | I actually generated my keys from the official scripts, so I do have that | 07:22:11 |
| 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 |
| pentane ⭔ | FWIW here's my current patch for https://github.com/GrapheneOS/platform_build: | 10:10:03 |
| pentane ⭔ | Download debug.patch | 10:10:36 |
| 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:11:17 |
| pentane ⭔ | Oh and we should also write a better abstraction for the non-standard keys, it kinda pisses me off that we need to specify them separately in keysToGenerate and in keyMappings in modules/signing.nix | 10:22:18 |
| pentane ⭔ | https://github.com/nix-community/robotnix/commit/75cf4f78b6fbb3a402a22b848ec967880ddf56f6
https://github.com/nix-community/robotnix/commit/fc99ff973428ef1c2e2bff427ce403d01a5f2b19 | 22:01:43 |
| puffnfresh | compiling 2025-11-09 now and will test signing using that branch | 22:17:11 |
 magic_rb | @cyclopentane:aidoskyneen.eu are you polish? The text on your github pfp looks polish | 22:03:45 |
| pentane ⭔ | (already tested 2025-11-09 on a tegu with the official signing script btw, I'll merge as soon as upstream pushed 2025110800 to stable) | 22:18:03 |
