The release-verify Skill — Five Steps Before Any Install

Installing software from a release tarball without checking its signature is a supply-chain risk. The release-verify skill is the answer to one question: what does a Datarim consumer run before unpacking a release?

Datarim releases are published from Arcanada-one/datarim via the release.yml workflow and signed with Sigstore cosign in keyless mode, using GitHub OIDC as the identity source. Each release ships a CycloneDX SBOM and a SLSA Level 2 build-provenance attestation. The skill encodes the five-step verification recipe so an agent can run it without fetching external documentation.

What ships per release

Every release tag produces six artefacts: a source tarball, a SHA-256 checksum file, a cosign bundle for the tarball, a CycloneDX SBOM, a cosign bundle for the SBOM, and a server-side SLSA L2 attestation attached to the release via gh attestation verify. The source tarball is produced by git archive HEAD with the tag as prefix.

The five-step recipe

Step 1 downloads all release artefacts with gh release download. Step 2 verifies the tarball hash with sha256sum -c. Step 3 runs cosign verify-blob against the tarball, binding it to the exact workflow URL and tag. Step 4 runs the same cosign check against the SBOM. Step 5 verifies the SLSA build provenance with gh attestation verify.

Any non-zero exit from any step means the artefact is untrusted and should not be installed. Each step proves a different property. The checksum in step 2 proves the tarball arrived intact. The cosign verification in step 3 proves it was built by release.yml on that exact tag in Arcanada-one/datarim, with the signature anchored in the Sigstore Rekor transparency log. The SLSA attestation in step 5 proves the artefact was built by GitHub-hosted runners from source at that commit.

The skill is explicit about what a checksum alone does not prove: an attacker who replaces the tarball can replace the .sha256 file at the same time. The cosign step is the one that ties the tarball to a specific build origin and cannot be forged without access to the OIDC token from that exact workflow run.

The --certificate-identity flag matters

One specific counter-example in the skill: running cosign verify-blob with only --certificate-oidc-issuer and without --certificate-identity accepts a signature from any signer that used the same OIDC issuer. Any GitHub Actions workflow from any repository could mint a certificate and sign an arbitrary tarball. The identity flag pins the check to the exact workflow file and tag.

Prerequisites and scope

The recipe requires cosign ≥ 3.0, gh ≥ 2.40, sha256sum, and jq. The skill applies only to release tarballs. For git-checkout working copies, signature verification goes through git commit signing, which is a separate policy.

Read what Datarim is for the overall framework picture, or see the security-baseline skill for the S4 supply-chain rules that make this recipe mandatory.