feat(ci): verify the kernel hash under two checked-in kernel.org PGP keys

[mcfbytes]

Stacked on #42. Base is fix/kernel-hash-sync-url so this PR shows only its own diff. Retarget to master once #42 merges.

The gap

renovate-hash-sync.yml fetched kernel.org's PGP-clearsigned sha256sums.asc and grepped it as plain text, never verifying the signature. The .asc extension was doing no work — we'd have got the identical result from a plain text file. Trust rested entirely on TLS plus the CDN, and GitHub's Ubuntu runners ship no kernel.org keyring, so nothing on the box could have checked it even incidentally.

The exposure is narrow but real: anything able to serve us a manifest — a compromised mirror, a mis-issued certificate, or a bug in our own URL construction (exactly what #42 fixed) — could hand us a hash we'd commit to linux.hash. Buildroot would then dutifully "verify" the downloaded tarball against it and pass. The hash file would be self-consistently wrong: every check green, contents attacker-chosen.

Note: GPG is not a replacement for linux.hash

Worth stating explicitly, since it was the natural first instinct. linux.hash is Buildroot's own file format, consumed by its download infrastructure — Buildroot has no PGP support to defer to, so the hash file is its integrity mechanism. It's also the human-reviewable artifact that makes a bump PR auditable.

So this isn't an alternative to the stored hash. It's the missing provenance layer for how the value gets into it. The hash stays; what changes is that it can now only be written from signed input.

What this does

Two independent signatures, verified against keys committed in .github/keys/ and never fetched at run time — a key pulled from the network at the moment of use is not a trust root, it's just another thing the attacker serves you.

	path A	path B
artifact	linux-<ver>.tar.sign	sha256sums.asc
signer	Greg Kroah-Hartman	kernel.org checksum autosigner
covers	the uncompressed .tar	series-wide checksum manifest
hash from	sha256sum of the verified .tar.xz	gpg's verified plaintext

Both must verify and agree, or the step fails hard and refuses to touch linux.hash. A signature failure is a supply-chain event, never downgraded to the warn-and-skip path used for network errors.

Three load-bearing details:

1. Path A ties the signature to the exact file downloaded. The .sign covers the uncompressed tar but Buildroot hashes the .tar.xz, so we decompress the .xz we actually fetched and verify that stream — a tampered .xz can't decompress to signed content — then hash the .xz.
2. Path B parses only gpg's output, never the raw .asc. Grepping the signed file directly is the classic way this control gets implemented and defeated simultaneously.
3. Pinned by fingerprint via the VALIDSIG line on --status-fd, not gpg's exit status (can be 0 for a good-but-expired key) or its human-readable output (influenceable via filename).

The two keys are not equally trustworthy

ADR 0021 §4 records this honestly rather than implying uniform assurance:

• Maintainer key — cross-checked. Fingerprint 647F2865 4894E3BD 457199BE 38DBBDC8 6092693E is published on https://www.kernel.org/signature.html, so the committed key is verifiable against an authoritative kernel.org document.
• Autosigner key — TOFU, and that's a real weakness. kernel.org publishes neither the key nor its fingerprint anywhere findable (signature.html describes the system but lists no fingerprint; no autosigner.asc under /pub/linux/kernel/; keys.openpgp.org 404s it). It was obtainable only from keyserver.ubuntu.com, which accepts unverified uploads.

Pinning it still buys something — it detects a future change of signer or manifest provenance, which an unverified fetch cannot — but it isn't an independently-rooted anchor, and that's precisely why path A exists rather than path B alone. kernel.org itself states the checksums are "NOT intended to replace developer signatures."

Verification

Ran the real step extracted from the final YAML, not a paraphrase:

• 6.18.38 (currently pinned): both paths independently re-derive ac26e508..., matching the hash already checked in — which cross-validates the existing pin under two signatures. Idempotent: PATCH_HASH_CHANGED=0, file untouched.
• 6.18.39 (simulated Renovate bump): both paths agree on a7a7e3d2...; only the sha256 line rewritten, header comment preserved; PATCH_HASH_CHANGED=1.
• Cost: ~4s per run; the 147 MB download is ~1.3s on the CDN. The cost concern behind the original "no keyring management here yet" shortcut turned out not to exist.

Negative tests — verification that can't reject bad input is theater:

case	result
tampered manifest body	rejected
keyring missing the signer	rejected
valid signature from the wrong checked-in key	rejected
correct key + correct fingerprint	accepted

The third confirms the fingerprint pinning is doing real work, not just accepting any good signature.

shellcheck clean on the step body.

Out of scope, but noticed

actionlint flags github.event.pull_request.head.ref used directly in the inline script of the pre-existing commit-and-push step — a script-injection vector in a workflow with contents: write. It predates this PR (present on master) and is unrelated, so I left it alone, but it's worth a follow-up.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UFdgJXQKvrucXeKDami499

[Copilot]

Pull request overview

This PR hardens the Renovate kernel-hash refresh workflow by requiring cryptographic provenance: it now verifies kernel.org-provided signatures using two checked-in OpenPGP public keys before updating Buildroot’s linux.hash, and documents the threat model and rationale.

Changes:

• Update renovate-hash-sync.yml to verify both the kernel tarball’s developer signature and the series checksum manifest signature, requiring both paths to validate and agree on the sha256.
• Add checked-in kernel.org public keys under .github/keys/ and document their provenance/trust characteristics.
• Document the decision and rationale in ADR 0021 and update Renovate documentation accordingly.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
.github/workflows/renovate-hash-sync.yml	Implements dual-signature verification and fingerprint pinning before rewriting linux.hash.
docs/renovate.md	Updates the Renovate workflow documentation to reflect the new signature verification model and ADR reference.
docs/decisions/0021-kernel-hash-gpg-verification.md	New ADR describing the threat model, decision, and operational consequences.
.github/keys/README.md	Documents the checked-in PGP keys as trust roots and how to verify/extend them.
.github/keys/kernel.org-gregkh.asc	Adds the kernel stable maintainer public key used for path A verification.
.github/keys/kernel.org-autosigner.asc	Adds the kernel.org checksum autosigner public key used for path B verification.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.