Verify a FosterStack Cache release yourself
+Each stage of a release is signed on its own, and all the signatures are verified together before anything is published. This page shows how to check that yourself, with commands you run.
+Draft for the next release. [TO-VERIFY] marks anything not yet run against a real release.
+ +1. Signed at every stage, verified together
+The release is built, rebuilt independently, checked and then authorized, and each stage signs a statement under its own identity. The release step verifies all of them together. The image is built from signed packages, with no base image.
+# {TV}: identities, workflow names and the exact verify command per stage are not final.
+$ cosign verify ghcr.io/fosterstack/cache:${VER} \
+ --certificate-identity-regexp="<per-stage identity>" \
+ --certificate-oidc-issuer='https://token.actions.githubusercontent.com'
+
+ 2. About the exact digests
+Every statement names the image by digest, never by tag. The digest you verified is the digest in the release manifest, at both registries. [TO-VERIFY]
+# {TV}: manifest layout may differ from 0.2.1.
+$ jq -r '.images[] | "\(.variant) \(.digest)"' release-manifest.json
+
+ 3. Build provenance
+# {TV}: signer workflow and --source-ref for the new chain.
+$ gh attestation verify oci://ghcr.io/fosterstack/cache:${VER} \
+ --repo fosterstack/cache \
+ --signer-workflow <build-stage workflow> \
+ --source-ref "refs/tags/v${VER}"
+ [TO-VERIFY] Say here, in one sentence, what the build-stage record covers. Make no SLSA level claim unless the matrix condition for it has passed.
+ +4. The SBOM
+# {TV}: file name, format and what the SBOM lists for an image with no base image.
+$ jq '{{spdxVersion, name, packages: (.packages | length)}}' <sbom file>
+
+ 5. Where the Go dependencies came from
+[TO-VERIFY] dependency-provenance.json records where each vendored Go dependency came from and lets you re-derive it. Describe the file and the one command that re-derives or checks it.
# {TV}: command not defined yet.
+$ <check dependency-provenance.json>
+
+ 6. The inputs the image was assembled from
+[TO-VERIFY] The inputs manifest lists every package the image was assembled from, by digest. Describe it and show the one command that checks it.
+# {TV}: command not defined yet.
+$ <check the inputs manifest>
+
+ 7. Trust boundaries
+[TO-VERIFY] TO-FILL, at most 400 words, from the build-system dossier (section 2c and 2d): for each stage, who holds which key or credential, and what a compromise of that stage can and cannot do. The owner explains it back in his own words before this section ships.
+ +What these checks do and do not prove
+-
+
- A valid signature proves who signed these exact bytes. +
- Provenance proves which workflow and run produced them. +
- None of it proves the software has no bugs. It proves the release is the one we built, the way we describe. +
Related: how releases are built and signed and security policy.
+ +