security(ci): verify kubeconform against a pinned digest before installing

[LukasWodka]

What and why

The template job installed kubeconform like this:

curl -sSL https://github.com/yannh/kubeconform/releases/latest/download/kubeconform-linux-amd64.tar.gz \| tar xz -C /usr/local/bin

Two independent problems:

1. releases/latest is a mutable pointer. The binary this job executed changed whenever upstream cut a release. We were not pinned to anything.
2. curl | tar makes verification impossible, not just absent. Piping extracts bytes as they arrive, so there is no point at which a digest could be checked. The archive was unpacked onto PATH first and inspected never. curl also lacked -f, so an HTTP error body was fed to tar as if it were an archive.

The next step then executes that binary — four times per CI run, once per matrix platform.

Pin + digest

item	value
version	0.8.0 (was releases/latest)
asset	kubeconform-linux-amd64.tar.gz
SHA-256	9bc2bffbf71f261128533edaf912153948b7ff238f9a531ae6d34466ec287883
checksum source	the release's own CHECKSUMS asset — https://github.com/yannh/kubeconform/releases/download/v0.8.0/CHECKSUMS

The digest is taken from upstream's published CHECKSUMS file, not computed from a download (computing it from the bytes you just fetched authenticates nothing).

Version pin is behaviour-preserving:releases/latest currently 302-redirects to v0.8.0, confirmed.

Pattern copied from tracebloc/.github's actionlint.yml (version + SHA-256 + sha256sum -c) rather than invented.

The failure path that reports success — and why this one doesn't

sha256sum -c treats a malformed line as "no properly formatted checksum lines found", and whether that exits non-zero depends on the coreutils build: GNU exits 1, the macOS sha256sum exits 0. An empty or truncated digest variable is therefore a plausible way to ship a step that verifies nothing and still goes green. So the digest is asserted to be 64 hex characters before it is relied on.

Tested on ubuntu:22.04 (GNU coreutils 8.32) by executing the verbatim run: block extracted from this YAML, checking both the exit code and whether a binary landed on PATH:

case	exit	binary installed
published digest (happy path)	0	yes — prints v0.8.0
digest mismatch	1	no
empty digest var	1	no
truncated digest	1	no
uppercase digest	1	no
HTTP 404	22	no
real substitution: v0.8.0 digest vs the v0.7.0 asset	1	no

Every bad case fails closed and installs nothing.

Required checks

This touches the template job, which runs the 4-platform matrix (aks, bm, eks, oc), so helm-ci exercises the new step 4×. actionlint 1.7.7 clean on this file. No chart or values changes, so Prereqs / PATH persist / E2E are untouched.

Refs tracebloc/backend#1426

🤖 Generated with Claude Code

---

Note

Low Risk
CI-only workflow change with no chart or runtime impact; slightly reduces risk of unverified third-party binaries on runners.

Overview
The template job in helm-ci no longer installs kubeconform from releases/latest via curl | tar. It pins v0.8.0 with a SHA-256 from upstream’s CHECKSUMS, downloads the tarball to disk (curl -fsSL with retries), validates the digest (including a regex guard so empty/truncated digests cannot pass silently), and only then extracts and installs the binary.

This hardens CI supply-chain for the step that runs kubeconform on rendered Helm manifests across the four-platform matrix; manifest validation behavior is unchanged aside from using a fixed, verified binary.

^{Reviewed by Cursor Bugbot for commit 4dc2029. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

/fr-pass