Grilling: Signing + key policy #39

New Issue

2026-09-02T18:31:23Z

xavierk commented

2026-09-02 18:31:23 +00:00

Parent map: Fenris deb + rpm release plan

Question

Packaging GPG key policy: key creation + storage, what gets signed (rpm payload, deb, apt repo metadata — depends on chosen channel mechanics), publication points for the key, and rotation story outline.

Parent map: [Fenris deb + rpm release plan](https://git.bongbetic.com/xavierk/Fenris/issues/33) ## Question Packaging GPG key policy: key creation + storage, what gets signed (rpm payload, deb, apt repo metadata — depends on chosen channel mechanics), publication points for the key, and rotation story outline.

xavierk added this to the Wayfinder: Fenris deb + rpm release plan milestone 2026-09-02 18:31:23 +00:00

xavierk added the wayfinder:grilling label 2026-09-02 18:31:23 +00:00

xavierk added a new dependency 2026-09-02 18:34:07 +00:00

#38 Grilling: Lock channel + toolchain

xavierk added a new dependency 2026-09-02 18:34:10 +00:00

#42 Task: Compose release spec + ADR amending 0004

xavierk referenced this issue

2026-09-02 19:46:14 +00:00

Grilling: Lock channel + toolchain #38

xavierk self-assigned this 2026-09-02 19:48:50 +00:00

xavierk commented

2026-09-02 19:52:12 +00:00

Resolution

All recommendations (Q1–Q9) accepted.

What gets signed:

RPM payload: signed with the dedicated packaging key via rpmsign (nfpm config references it). Required — Gitea 1.27's served .repo sets gpgcheck=1 against the instance auto-key, whose private half is unreachable, so unsigned rpms or own-key rpms via that .repo both fail; signing is the only working dnf-native verification path.
.deb: NOT signed. apt never verifies .deb payload signatures; apt trust = instance-signed InRelease (signed-by keyring flow) + TLS + Acquire-By-Hash. Manual-download integrity covered by SHA256SUMS.
SHA256SUMS: clearsigned with the packaging key — trust anchor for manually downloaded release assets, independent of TLS.

Repo file consequence (surfaces new fact): Fenris ships its own packaging/fenris.repo + packaging/keys/fenris-packaging.asc; install docs use dnf config-manager --add-repo <raw-url> with gpgkey → our published key, repo_gpgcheck=0 (metadata left to TLS). Gitea's auto-generated .repo is a trap (gpgcheck against an instance key that never signed the package) and is never mentioned in docs.

Key structure: single dedicated packaging key, signing-capable, RSA 3072, UID Fenris Packaging <packaging@bongbetic.com>, 2-year expiry, renewed by re-export. No master/subkey hierarchy — ceremony without a CI fleet (single maintainer, manual builds per #37).

Private key storage: password manager only. Import → sign → delete from build-host keyring each release. Nothing permanent on any machine; exposure window minutes if build host compromised mid-release.

Public key publication: in-repo packaging/keys/ (raw URL doubles as gpgkey target), release notes each release, docs page. No keyservers — TOFU-over-TLS model, external infra adds nothing.

TOFU hardening (apt side): instance Debian Registry Key fingerprint published in install docs next to the curl-one-liner, closing the instance/TLS-path compromise hole to a documented constant. RPM side already closed by own-key .repo.

Rotation (outline; details stay in map fog): new key published alongside old → rpm signed with new key, fenris.repo gpgkey lists both URLs (dnf accepts multiple) → old key dropped after one release cycle.

Key creation command specifics, .repo file authoring, rpmsign wiring into make release = execution, out of this map's scope.

closes Grilling: Signing + key policy (#39)

## Resolution All recommendations (Q1–Q9) accepted. **What gets signed:** - RPM payload: signed with the dedicated packaging key via rpmsign (nfpm config references it). Required — Gitea 1.27's served `.repo` sets gpgcheck=1 against the instance auto-key, whose private half is unreachable, so unsigned rpms or own-key rpms via that .repo both fail; signing is the only working dnf-native verification path. - .deb: NOT signed. apt never verifies .deb payload signatures; apt trust = instance-signed InRelease (signed-by keyring flow) + TLS + Acquire-By-Hash. Manual-download integrity covered by SHA256SUMS. - SHA256SUMS: clearsigned with the packaging key — trust anchor for manually downloaded release assets, independent of TLS. **Repo file consequence (surfaces new fact):** Fenris ships its own `packaging/fenris.repo` + `packaging/keys/fenris-packaging.asc`; install docs use `dnf config-manager --add-repo <raw-url>` with gpgkey → our published key, repo_gpgcheck=0 (metadata left to TLS). Gitea's auto-generated .repo is a trap (gpgcheck against an instance key that never signed the package) and is never mentioned in docs. **Key structure:** single dedicated packaging key, signing-capable, RSA 3072, UID `Fenris Packaging <packaging@bongbetic.com>`, 2-year expiry, renewed by re-export. No master/subkey hierarchy — ceremony without a CI fleet (single maintainer, manual builds per #37). **Private key storage:** password manager only. Import → sign → delete from build-host keyring each release. Nothing permanent on any machine; exposure window minutes if build host compromised mid-release. **Public key publication:** in-repo `packaging/keys/` (raw URL doubles as gpgkey target), release notes each release, docs page. No keyservers — TOFU-over-TLS model, external infra adds nothing. **TOFU hardening (apt side):** instance Debian Registry Key fingerprint published in install docs next to the curl-one-liner, closing the instance/TLS-path compromise hole to a documented constant. RPM side already closed by own-key .repo. **Rotation (outline; details stay in map fog):** new key published alongside old → rpm signed with new key, fenris.repo gpgkey lists both URLs (dnf accepts multiple) → old key dropped after one release cycle. Key creation command specifics, .repo file authoring, rpmsign wiring into `make release` = execution, out of this map's scope. - closes #39

xavierk closed this issue

2026-09-02 19:52:19 +00:00

xavierk referenced this issue

2026-09-02 19:53:02 +00:00

Fenris deb + rpm release plan #33

xavierk referenced this issue

2026-09-02 20:09:33 +00:00

Grilling: Release cadence + stable/testing channel split #43

Sign in to join this conversation.