Skip to content

feat(fork-review-check): verify digest-pinned images and release binaries - #338

Open
Piotr1215 wants to merge 2 commits into
devops-1740/fork-review-checkfrom
devops-1740/fork-review-check-image
Open

Piotr1215 wants to merge 2 commits into
devops-1740/fork-review-checkfrom
devops-1740/fork-review-check-image

Conversation

@Piotr1215

Copy link
Copy Markdown
Contributor

Summary

Step 4 inputs for the fork review check: container images pinned by digest and release binaries pinned by sha256. Stacked on #337.

loft-enterprise now pins kine by tag and digest (loft-sh/loft-enterprise#8958, #8959), and the digest wins: bumping KINE_VERSION alone builds the old image under the new label. Checking that the digest matches the tag would also be wrong, because a fork tag can point at the wrong build (v0.14.16.vcluster.4 holds upstream kine v0.13.5). The design's rule covers both: the digest's provenance must name the fork's release workflow, the tag, and the tag's commit.

Key Changes

  • image mode: -image ghcr.io/<owner>/<name>:<fork-tag>@sha256:<digest> plus -signer-workflow <fork>=<workflow path>. Resolves the tag to S, runs gh attestation verify oci://IMAGE@DIGEST --owner ... --signer-workflow ... --signer-digest S --source-digest S --source-ref refs/tags/<tag> --deny-self-hosted-runners, then checks the fork commits like ref mode.
  • binary mode: -url <release asset URL> -sha256 <hex>. Downloads, compares sha256, verifies the asset attestation the same way.
  • Both fail closed on an unknown reference, a missing digest, or a missing signer workflow. Receipt inputs record digest or sha256 and the signer workflow.
  • live-image CI job runs image mode against the real registry for two cases.

Evidence

gh attestation verify with the flags above, run against the registry:

Pin Result
kine:v0.16.5.vcluster.1@sha256:7e722818… (main pin) verifies
kine:v0.14.16.vcluster.4@sha256:4ed2cd65… (release-4.10 pin) verifies
kine:v0.17.2.vcluster.0@sha256:7e722818… (version-only bump) rejected
kine:v0.14.16.vcluster.4@sha256:0675df8b… (upstream build behind that tag) rejected

Dependencies

TODO

  • live-image job shows attested for the main pin and rejected for the version-only bump.

References DEVOPS-1740

https://claude.ai/code/session_017edg9gFKBwMnmsAVXxEJzn

…ries

loft-enterprise now pins kine by tag and digest, and the digest wins: a
bump of KINE_VERSION alone builds the old image under the new label. A
check that the digest matches the tag would be wrong too, since a fork tag
can point at the wrong build (v0.14.16.vcluster.4 holds upstream kine
v0.13.5). The design's rule closes both: the digest's build provenance
must name the fork's release workflow, the tag, and the tag's commit.

image mode resolves the tag to its commit, runs gh attestation verify on
the digest with signer workflow, signer and source digest, source ref and
no self-hosted runners, then checks the fork commits like ref mode. binary
mode downloads a release asset, compares its sha256, and verifies the
asset's attestation the same way. Both fail closed on an unknown
reference or a missing signer workflow.

Checked against the registry with gh attestation verify: the kine digest
loft-enterprise pins verifies under v0.16.5.vcluster.1 and is rejected
under v0.17.2.vcluster.0; the live-image CI job repeats both cases.

References DEVOPS-1740

Claude-Session: https://claude.ai/code/session_017edg9gFKBwMnmsAVXxEJzn
Product builds need vendor verification and attested image and binary checks together. Merging the stacked base prevents either path from losing its evidence or fail-closed behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants