fix(signing): select GPG signing subkey for the Gradle/BouncyCastle AAR path#307
Merged
Merged
Conversation
…se64) Replaces the opaque base64-embedded Gradle files in the verify-signing-key-gradle job with a committed, reviewable project at .github/signing-selftest/ (settings.gradle.kts + build.gradle.kts, the latter mirroring llama-android/build.gradle.kts). The job now checks out the repo and runs `gradle -p .github/signing-selftest signMakeArtifact`. No behavior change — same useInMemoryPgpKeys path, same Gradle 8.14.3 — but a reviewer can now read exactly what the signing self-test executes instead of decoding a blob, which matters for a job whose purpose is trustworthy signing verification. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018pwn51YPBbtiuUyiLRrfrG
…path)
The Gradle useInMemoryPgpKeys (BouncyCastle) path failed with a null
PGPPrivateKey because the 2-arg form selects the primary key, whose secret
this BouncyCastle cannot unlock. gpg / maven-gpg-plugin auto-select the
4096-bit signing subkey (07D2D767) instead and sign fine — proven by the
green `verify-signing-key` (gpg) job vs the red `verify-signing-key-gradle`
job on the same key.
Wire an optional signing key id through both Gradle signing setups so they
select that subkey via the 3-arg useInMemoryPgpKeys(keyId, key, passphrase):
- .github/signing-selftest/build.gradle.kts (the isolated harness)
- llama-android/build.gradle.kts (the real AAR publish)
- publish.yml: pass MAVEN_GPG_KEY_ID: ${{ secrets.GPG_KEY_ID }} to the
harness step and both AAR publish steps.
When the id is unset, both fall back to the previous 2-arg behavior. Validate
green in the harness first, then the same code path covers the real AAR.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018pwn51YPBbtiuUyiLRrfrG
bernardladenthin
had a problem deploying
to
startgate
GitHub Actions
Error
bernardladenthin
had a problem deploying
to
maven-central
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
GitHub Actions
Failure
|
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
llama-androidAAR publish failing withCannot invoke "org.bouncycastle.openpgp.PGPPrivateKey.getPublicKeyPacket()" because "<parameter1>" is null. Gradle's 2-arguseInMemoryPgpKeysselects the primary GPG key, whose secret this BouncyCastle can't unlock;gpg/maven-gpg-plugin auto-select the 4096-bit signing subkey (07D2D767) and sign fine. Both Gradle signing setups now select that subkey via the 3-arguseInMemoryPgpKeys(keyId, key, passphrase)whenMAVEN_GPG_KEY_IDis set (env secretGPG_KEY_ID), falling back to the previous 2-arg behavior otherwise.verify-signing-key-gradleself-test project committed and readable at.github/signing-selftest/instead of an opaque base64 blob.Test plan
verify-signing-key(gpg) job is green onmain— the key/passphrase are valid.verify-signing-key-gradlejob reproduced the exact null-PGPPrivateKeyfailure onmain— confirming the bug is BouncyCastle-selecting-the-primary, not a bad key.verify-signing-key-gradlegoes green onmain(the harness only runs under themaven-centralenvironment gate onmain), proving the subkey selection. The real AAR publish runs the identical code + same secret, so it is covered by the same result.Related issues / PRs
Refs #306 (the preflight jobs this builds on).
Checklist
GPG_KEY_IDis a public key id (present in the key's fingerprint); the private key and passphrase never appear in any log (passphrase on fd 3,set -xnever enabled,::add-mask::ed).🤖 Generated with Claude Code
Generated by Claude Code