fix(ci-runner): verify the helm and yq downloads, and unstick yq #88

Merged

ryangr0 merged 1 commit from fix/ci-runner-verify-helm-yq into main 2026-08-05 16:12:11 +00:00

Conversation 0 Commits 1 Files changed 1 +20 -8

ryangr0 commented 2026-08-05 15:05:28 +00:00

Owner

Copy link

Cuts ci-runner 1.2.2, and carries a real change rather than a no-op bump.

Why a new patch instead of re-releasing 1.2.1

1.2.1 built and pushed fine — only signing failed, on the 2 GB tmpfs fixed in #87. But Harbor's immutable-tag rule (**.**.** on **) blocks re-pushing over 1.2.1, so workflow_dispatch on the existing tag would burn a ~22-minute build and then fail at push.

A new patch is the supported route, and it's what the failed-release summary already tells anyone reading it to do: "cut a new patch release — do not re-tag."

The actual change: two unverified binary downloads

Both were bare curls straight onto PATH in the image that runs every CI job in the org:

# helm — unverified, piped into tar
RUN curl -fsSL "https://get.helm.sh/helm-v${HELM_VERSION}-linux-amd64.tar.gz" \
      | tar -xz -C /tmp linux-amd64/helm && ...

# yq — unverified, written directly to /usr/local/bin
RUN curl -fsSL ".../yq_linux_amd64" -o /usr/local/bin/yq && chmod 0755 ...

Whatever integrity TLS gives you ends at the CDN; neither artifact itself was pinned. cosign and syft in this same file are already checksum-verified, so this was an inconsistency as much as a gap. Both now follow that pattern: download to /tmp, sha256sum -c -, install, clean up.

Checksums were cross-checked against upstream's own published values, not just computed from my download — which would only prove the file didn't change between two fetches:

	verified against
helm 3.21.3	https://get.helm.sh/helm-v3.21.3-linux-amd64.tar.gz.sha256sum
yq 4.53.3	column 19 of the release checksums file, which checksums_hashes_order identifies as SHA-256

yq was nine minors stale

4.44.3 → 4.53.3. It already carried a Renovate annotation:

# renovate: datasource=github-releases depName=mikefarah/yq
ARG YQ_VERSION=4.44.3

So the annotation isn't doing what it looks like it's doing. Worth investigating separately — if it's silently not matching, the other four pins in this file (helm, cosign, syft, node) may be equally stuck, and I'd rather know that than keep hand-bumping.

helm is deliberately not bumped. Upstream is on 4.2.3; a Helm major is a migration, not a version bump.

Verified

• both checksum lines pass against the real downloaded artifacts
• a corrupted checksum is correctly rejected (FAILED, non-zero exit)
• yq 4.53.3 is a statically linked amd64 ELF

What this run should prove

It's the first release with #87's gate fix, so it exercises the whole chain end to end: seccomp profile → grype with real disk → budget verdict → cosign signature. If it goes green, ci-runner finally has a signed artifact and the same path is ready for cve-gate.

Cuts **ci-runner 1.2.2**, and carries a real change rather than a no-op bump. ## Why a new patch instead of re-releasing 1.2.1 1.2.1 built and pushed fine — only signing failed, on the 2 GB tmpfs fixed in #87. But **Harbor's immutable-tag rule (`**.**.**` on `**`) blocks re-pushing over `1.2.1`**, so `workflow_dispatch` on the existing tag would burn a ~22-minute build and then fail at push. A new patch is the supported route, and it's what the failed-release summary already tells anyone reading it to do: *"cut a new patch release — do not re-tag."* ## The actual change: two unverified binary downloads Both were bare curls straight onto PATH **in the image that runs every CI job in the org**: ```dockerfile # helm — unverified, piped into tar RUN curl -fsSL "https://get.helm.sh/helm-v${HELM_VERSION}-linux-amd64.tar.gz" \ | tar -xz -C /tmp linux-amd64/helm && ... # yq — unverified, written directly to /usr/local/bin RUN curl -fsSL ".../yq_linux_amd64" -o /usr/local/bin/yq && chmod 0755 ... ``` Whatever integrity TLS gives you ends at the CDN; neither artifact itself was pinned. cosign and syft in this same file are already checksum-verified, so this was an inconsistency as much as a gap. Both now follow that pattern: download to `/tmp`, `sha256sum -c -`, install, clean up. **Checksums were cross-checked against upstream's own published values**, not just computed from my download — which would only prove the file didn't change between two fetches: | | verified against | |---|---| | helm 3.21.3 | `https://get.helm.sh/helm-v3.21.3-linux-amd64.tar.gz.sha256sum` | | yq 4.53.3 | column 19 of the release `checksums` file, which `checksums_hashes_order` identifies as SHA-256 | ## yq was nine minors stale `4.44.3 → 4.53.3`. It **already carried a Renovate annotation**: ```dockerfile # renovate: datasource=github-releases depName=mikefarah/yq ARG YQ_VERSION=4.44.3 ``` So the annotation isn't doing what it looks like it's doing. Worth investigating separately — if it's silently not matching, the other four pins in this file (helm, cosign, syft, node) may be equally stuck, and I'd rather know that than keep hand-bumping. **helm is deliberately not bumped.** Upstream is on 4.2.3; a Helm major is a migration, not a version bump. ## Verified - both checksum lines pass against the real downloaded artifacts - a corrupted checksum is correctly rejected (`FAILED`, non-zero exit) - yq 4.53.3 is a statically linked amd64 ELF ## What this run should prove It's the first release with **#87's gate fix**, so it exercises the whole chain end to end: seccomp profile → grype with real disk → budget verdict → cosign signature. If it goes green, ci-runner finally has a signed artifact and the same path is ready for cve-gate.

ryangr0 added 1 commit 2026-08-05 15:05:28 +00:00

fix(ci-runner): verify the helm and yq downloads, and unstick yq ... 48ccd9eaeb

Both were bare curls of a binary straight onto PATH in the image that runs every CI job in the
org — helm piped unverified into `tar -xz`, yq written directly to /usr/local/bin. Whatever
integrity TLS provides ends at the CDN; neither artifact itself was pinned. cosign and syft in
this same file are checksum-verified, so this was an inconsistency as much as a gap.

Both now follow that pattern: download to /tmp, `sha256sum -c -`, install, clean up.

Checksums were cross-checked against upstream's own published values, not just computed from my
download (which would only prove the file did not change between two fetches):

  helm 3.21.3   matches https://get.helm.sh/helm-v3.21.3-linux-amd64.tar.gz.sha256sum
  yq   4.53.3   matches column 19 of the release `checksums` file, which
                `checksums_hashes_order` identifies as SHA-256

yq also goes 4.44.3 -> 4.53.3. It carried a Renovate annotation and was still nine minor versions
behind, so the annotation is not doing what it looks like it is doing — worth a look separately.
Staying within v4; helm is deliberately NOT bumped, since upstream is on 4.2.3 and a Helm major is
a migration rather than a version bump.

Verified: both checksum lines pass against the real artifacts, a corrupted one is rejected, and
the yq binary is a static amd64 ELF.

This also exists to cut ci-runner 1.2.2. 1.2.1 built and pushed but never got signed — the gate
died on a 2g tmpfs (#87) — and Harbor's immutable-tag rule means the fix cannot be re-pushed over
it. A new patch is the supported route, which is what the failed-release summary already tells
anyone reading it to do.

ryangr0 merged commit b00a14fb46 into main 2026-08-05 16:12:11 +00:00

ryangr0 referenced this pull request from a commit 2026-08-05 16:12:12 +00:00

Merge pull request 'fix(ci-runner): verify the helm and yq downloads, and unstick yq' (#88) from fix/ci-runner-verify-helm-yq into main

ryangr0 referenced this pull request 2026-08-06 19:56:05 +00:00

fix(ci-runner): annotate CLAUDE_CODE_VERSION for Renovate, and bump it #94

ryangr0 referenced this pull request from a commit 2026-08-06 19:56:05 +00:00

fix(ci-runner): annotate CLAUDE_CODE_VERSION for Renovate, and bump it

ryangr0 referenced this pull request 2026-08-08 05:05:58 +00:00

fix(release): inline changed-image detection, dropping the reusable workflow #101

ryangr0 referenced this pull request from a commit 2026-08-08 05:05:59 +00:00

fix(release): inline changed-image detection, dropping the reusable workflow

ryangr0 referenced this pull request from a commit 2026-08-08 06:27:08 +00:00

fix(act-runner): pin act and verify the download

ryangr0 referenced this pull request 2026-08-08 06:32:12 +00:00

fix(act-runner): pin act and verify the download #108

ryangr0 referenced this pull request from a commit 2026-08-08 06:35:31 +00:00

fix(helm-deploy): verify all five tool downloads

ryangr0 referenced this pull request 2026-08-08 06:35:49 +00:00

fix(helm-deploy): verify all five tool downloads #117

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

  

released

No labels

pull-request

released

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

webgrip/infrastructure!88

No description provided.