Repository navigation
docs: document the CI signing subkey - #39
Merged
Merged
Conversation
Releases still sign locally with the YubiKey primary, but a dedicated ed25519 signing subkey now exists for CI, stored as SIGNING_KEY and SIGNING_KEY_PASSPHRASE in the release environment. - Record both fingerprints, why the primary stays [SC], and why CI must sign with gpg rather than KOTLIN_TOOLCHAIN_SIGNING_KEY. - Add the expiry, rotation, revocation and key publishing procedures.
The built-in signer can't use the new CI signing subkey either: with an [SC] primary, BouncyCastle's addSigningKey picks the stub primary in the export and fails, while gpg signs fine with the same export. - Add a ci-subkey section with the failure, why the primary stays [SC], and that CI must sign through the signForCentral plugin too. - Replace the stale releasing.adoc quote and update the verdict, the upstream note and the next steps; cross-link both docs.
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
KTC-6065 (allow configuring a signing subkey) was filed from our report. Once fixed, CI can sign with the built-in signer, so the staged-publication workaround can go if releases move to CI. - Mention it in the ci-subkey section, the upstream issue table and the next steps; agent-based signing remains untracked.
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
1 participant
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.
What
Documents the new CI signing subkey in two docs:
docs/releasing.adoc: the intro no longer claims the signing key never leaves local hardware. A new Signing keys section covers:1F3C…2C9D) and the ed25519 CI subkey (2B2E…A3BB);[SC];--export-secret-subkeys '<fpr>!') and removed from the local keyring;SIGNING_KEY/SIGNING_KEY_PASSPHRASEsecrets in thereleaseenvironment;docs/kotlin-toolchain-evaluation.adoc: a newci-subkeysection records that Kotlin Toolchain 0.13.0's built-in signer can't use the subkey export, so CI must also sign through thesignForCentralplugin. The verdict, gaps, upstream notes and next steps are updated, and the two docs link to each other.Why
Releases still sign locally with the card. The subkey exists so a future release workflow can sign in CI without the YubiKey. Its secret is only in the GitHub
releaseenvironment, and it can be revoked without touching the primary.Notes for review
[SC]. Tested with gpg 2.4.9: afterchange-usageto certify-only, gpg and gpgv reject the primary's existing signatures ("No public key"), with or without a signing subkey. GnuPG has checked sign usage at verify time since 2.2.9 (#4014).[SC]primary, BouncyCastle'saddSigningKeypicks the stub primary in the export and throws an NPE. gpg signs correctly with the same export. Hence the doc warns against exposing the key asKOTLIN_TOOLCHAIN_SIGNING_KEY.