[seantronsen]

Description

Implements this repo's side of #43 (decision A2): releases are signed through the existing key chain (root key -> repo key -> per-run release key), but format-agnostically. Packages ship unsigned; one signature over GoReleaser's checksums.txt covers every package, archive, and binary. A central repo (todo-signing-repo, not built yet) later verifies the chain and publishes to dnf/apt with its own archive key.

• gpg-sign-artifacts: rewritten as one job. Creates a 1-day release key, certifies it with the repo key, signs checksums.txt, verifies, and uploads checksums.txt.asc + pubkey-{signing,repo,org}.asc. Outputs verification notes for the release. Tag pushes only.
• gpg-verify-trust-chain: rewritten. Checks the chain against a pinned root key fingerprint, the repo key's certified name, expiry/revocation, and file signatures. The central repo will reuse it.
• release-modify (new): appends/replaces notes and adds/replaces files on a draft release.
• release-publish (renamed from publish-release): both it and release-modify fail if the release is already public.
• build-release-goreleaser: nfpm package signing removed.
• Removed the deprecated workflows and actions (none reached production), and the runtime fetches from gpg-signing-manager.
• Docs: README split into docs/ (workflows, actions, GoReleaser, signing, distribution, Makefile.common).

Stacked on #48. Closes #43.

Breaking changes

• Removed: build-publish-container-goreleaser, go-build-release, docker-build-release, build-rpm-quadlet, validate-rpm-quadlet, release-signed-artifacts, and the gpg-configure-release-keys, gpg-sign-rpm, gpg-check-key-expiration actions.
• publish-release -> release-publish.
• build-release-goreleaser drops the gpg-key/gpg-key-passphrase secrets and GPG_KEY_PATH; configs still referencing {{ .Env.GPG_KEY_PATH }} fail to render.
• Signing needs checksum.name_template: checksums.txt and only the repo key secret (GPG_REPO_CERT_KEY_B64); GPG_REPO_KEY_B64 is unused.

Caveats

• Prereleases are signed but never published to the distro repos: we only support current stable releases.
• The central repo binds a release to its repo through the repo key's certified name (<owner>/<repo> RPM Signing Key). Simpler than a per-repo fingerprint list, but one mis-named certification by the root key holder would let a repo publish as another. Switching to a list later only touches the central repo.

Optional improvements (not in this PR)

• A tag-only release Environment for the repo key, plus an org-wide v* tag ruleset. Environments are per repo and can't be enforced org-wide, and without the ruleset anyone who can push a v* tag still gets the key; together they mainly help where write access is broader than the set of maintainers who tag releases.

Testing

Testbed: OpenCHAMI/github-actions-testbed#13 (signing runs on a v* tag push there). Also tested locally: signing/verification failure cases in podman, a real GoReleaser snapshot signed and verified end to end, and release-modify/release-publish logic against a stubbed gh.

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update
• Build system/CI

---

• I agree to follow the Code of Conduct.

[synackd]

Looking at this because of OpenCHAMI/github-actions-testbed#13.

So we're only signing the checksum list so package signing is up to the package distributor now? Will we be distributing our own packages or is that out-of-scope? @alexlovelltroy @travisbcotton

[seantronsen]

Looking at this because of OpenCHAMI/github-actions-testbed#13.

So we're only signing the checksum list so package signing is up to the package distributor now? Will we be distributing our own packages or is that out-of-scope? @alexlovelltroy @travisbcotton

@synackd It depends a bit on what you mean, but here's my answer as I understand the question.

---

Yes, we'll distribute our own packages; that's in scope. In the new design, publishing packages to distro repositories (dnf/yum, apt, etc.) is fully decoupled from development in the OpenCHAMI service repos (e.g., metadata-service). A separate central repo (working name "distributor"; the name is still pending) runs a polling workflow about every 10 minutes to look for new releases:

1. New releases are pulled from each service repo.
2. The trust chain and the signature on checksums.txt are verified, and every package is checked against those checksums.
3. If all checks pass, the rpms are re-signed with the OpenCHAMI archive key and published to our dnf repository, and the debs are published to our apt repository. Each repository's metadata is regenerated and signed with the same key (for apt, the signed Release file lists every deb's hash). Hosting (S3 or otherwise) is still to be decided.

---

Why sign only the checksums file? Mostly simplicity. It's a Debian-flavored strategy: one signature over checksums.txt vouches for every file it lists (rpms, debs, archives, binaries), so service repos don't need format-specific signing for each package. Signing that matches each distro's conventions happens once, centrally, in the distributor.

[synackd]

I found no new regression in the rebased changes, but I am withholding approval until the corresponding testbed is updated and its results demonstrate the current revision working. See: OpenCHAMI/github-actions-testbed#13 (comment)