diff --git a/sitemap.xml b/sitemap.xml index bd1c604..6e84a15 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -20,4 +20,8 @@ weekly 1.0 + + https://fosterstack.com/verify-a-release/ + 2026-10-08 + diff --git a/verify-a-release/index.html b/verify-a-release/index.html new file mode 100644 index 0000000..012b0cd --- /dev/null +++ b/verify-a-release/index.html @@ -0,0 +1,162 @@ + + + + + +Verify a FosterStack Cache release yourself: signed at every stage + + + + + + + + + +
+ +
Infrastructure worth keeping — and kept patched.
+
+
+ +

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

+ + +

Related: how releases are built and signed and security policy.

+
+ Releases on GitHub + FosterStack home +
+
+ + +