Skip to content

infra: reuse SIGNING_KEY for apt/rpm repo publishing#1483

Merged
kixelated merged 2 commits into
mainfrom
claude/focused-blackwell-fac718
May 24, 2026
Merged

infra: reuse SIGNING_KEY for apt/rpm repo publishing#1483
kixelated merged 2 commits into
mainfrom
claude/focused-blackwell-fac718

Conversation

@kixelated
Copy link
Copy Markdown
Collaborator

Summary

  • Replace the separate REPO_SIGNING_KEY / REPO_SIGNING_KEY_ID secrets in the apt/rpm publish scripts and workflows with the existing SIGNING_KEY (and optional SIGNING_PASSWORD) already used by the Maven Central release workflow.
  • Auto-detect the long key id from the imported keyring instead of carrying it as a secret. A fresh ephemeral GNUPGHOME only ever holds the one imported key.
  • Update infra/README.md to reflect the shared key and drop the now-unnecessary step that minted a dedicated repo signing key.

Why

The apt-repo / rpm-repo workflows were failing on moq-dev/moq because none of the REPO_SIGNING_KEY* or R2_* secrets were ever configured (see the latest apt-repo run, which aborts on R2_ACCOUNT_ID: parameter null or not set). Reusing SIGNING_KEY removes one secret to manage and keeps the GPG identity consistent across release surfaces.

The R2 secrets still need to be added separately. After this PR lands, the only secrets required to unblock the workflows are R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, and R2_SECRET_ACCESS_KEY.

Test plan

  • Add the three R2 secrets to moq-dev/moq.
  • Run gh workflow run apt-repo.yml --repo moq-dev/moq -f tag=<existing-deb-tag> and confirm the run signs the Release file and uploads to apt-moq-dev.
  • Same for rpm-repo.yml against an existing rpm-bearing tag.

(Written by Claude)

🤖 Generated with Claude Code

The apt/rpm publish workflows required separate REPO_SIGNING_KEY and
REPO_SIGNING_KEY_ID secrets, but the repo already has a SIGNING_KEY
(plus optional SIGNING_PASSWORD) used by the Maven Central release.
Reuse them to avoid managing a second GPG key and to unblock the
currently-failing apt-repo and rpm-repo workflows.

The key id is now auto-detected from the imported keyring instead of
being passed in as a secret, since a fresh GNUPGHOME contains only the
one imported key.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 24, 2026

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a6825927-3579-4339-aba7-2de4d20c4715

📥 Commits

Reviewing files that changed from the base of the PR and between 8951475 and 23250d9.

📒 Files selected for processing (2)
  • infra/apt/publish.sh
  • infra/rpm/publish.sh

Walkthrough

This pull request consolidates GPG signing infrastructure across apt and rpm package repositories. Previously, each package type maintained separate REPO_SIGNING_KEY and REPO_SIGNING_KEY_ID secrets; now both reuse the existing SIGNING_KEY and SIGNING_PASSWORD GitHub Actions secrets shared with Maven Central/Kotlin releases. Both workflow files and publish scripts are updated to import the signing key into a temporary GNUPGHOME, automatically derive the long key ID from imported secret keys, conditionally enable passphrase loopback mode, and sign repository metadata using the extracted key ID. Documentation is updated to reflect the new bootstrapping process and consolidated secret strategy.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the main change: replacing separate signing key variables with a shared SIGNING_KEY across apt/rpm repository publishing workflows.
Description check ✅ Passed The description is well-related to the changeset, explaining the motivation for reusing SIGNING_KEY, the specific changes made, and the test plan for validation.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/focused-blackwell-fac718
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch claude/focused-blackwell-fac718

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@infra/apt/publish.sh`:
- Around line 96-97: The script currently picks the first secret key via the
gpg/awk pipeline (KEY_ID), which can silently pick the wrong key; change the
logic to enumerate secret keys with gpg --list-secret-keys --with-colons
--keyid-format=long, count the number of '^sec:' entries and if the count is not
exactly 1 print a clear error referencing SIGNING_KEY and exit non-zero,
otherwise extract that single key id and assign it to KEY_ID (keep reference to
the existing KEY_ID variable and the gpg/awk selection logic for the successful
path).

In `@infra/rpm/publish.sh`:
- Around line 76-77: The current extraction of KEY_ID from gpg output is brittle
when multiple secret keys exist; change the logic around the gpg
--list-secret-keys --with-colons --keyid-format=long pipeline to first count
matching "sec" entries and validate cardinality: if zero, fail with a clear
error; if >1, fail and ask the caller to specify which key via SIGNING_KEY
(fingerprint or keyid) rather than silently picking the first; if exactly one,
assign that key to KEY_ID. Use the same gpg listing invocation but add a
pre-check that filters by the provided SIGNING_KEY (if set) or enforces a single
matching sec entry before setting KEY_ID.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f557d241-2128-4c3d-8405-27e4882c220d

📥 Commits

Reviewing files that changed from the base of the PR and between cbb7f67 and 8951475.

📒 Files selected for processing (5)
  • .github/workflows/apt-repo.yml
  • .github/workflows/rpm-repo.yml
  • infra/README.md
  • infra/apt/publish.sh
  • infra/rpm/publish.sh

Comment thread infra/apt/publish.sh Outdated
Comment thread infra/rpm/publish.sh Outdated
Silently picking the first sec row from a multi-key payload would let
the apt/rpm metadata be signed by the wrong key, which consumers would
then fail to verify against the published archive keyring. Count the
imported secrets and exit non-zero if it isn't exactly one.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kixelated kixelated merged commit 94ed0c2 into main May 24, 2026
1 check passed
@kixelated kixelated deleted the claude/focused-blackwell-fac718 branch May 24, 2026 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant