Verify a release

Every install route obtains the same signed artifacts, so the verification steps are written once here. The binary route runs them for you as part of its paste block; the Docker and Kubernetes routes verify the image and the manifest separately, before you apply them.

A signature that does not verify means the file is not ours. Do not run it.

Checksums

SHA256SUMS lists both archives with bare relative names, so -c works in whatever directory you downloaded into:

sha256sum -c SHA256SUMS

Expect one OK per archive you downloaded. Add --ignore-missing if you only fetched one of the two.

A checksum fetched from the same host as the artifact proves the download was not truncated. It proves nothing about provenance: whoever can serve you a modified tarball can serve a matching SHA256SUMS beside it. The signature is the control that answers that question, which is why it runs first and the checksum runs against a file it has already vouched for.

Signatures

Signing is cosign keyless: there is no public key to trust and no key of ours to leak. The signing identity is a GitHub Actions workflow, and the attestation is in the public Rekor transparency log.

The identity changes with every release

--certificate-identity is pinned to the release tag. Take it from the release notes of the version you downloaded — every release prints the command in full. Do not copy an identity from an older release; it will fail, correctly.

Each artifact carries its own <name>.cosign.bundle:

cosign verify-blob \
  --bundle SHA256SUMS.cosign.bundle \
  --certificate-identity <the identity printed in that release's notes> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  SHA256SUMS

For agent-v0.1.3 that identity is:

https://github.com/WireWatch/wirewatch/.github/workflows/agent-release.yml@refs/tags/agent-v0.1.3

That string names the producing repository, which is private, while the releases are hosted in the public one. It is an OIDC subject for keyless signing, not a link — nothing resolves it, and a 404 there is expected rather than a problem.

The archives and agent-k8s.yaml verify the same way against their own bundles.

The container image

The image is signed by digest, never by tag. Read the digest first — it is the Digest: line:

docker buildx imagetools inspect ghcr.io/wirewatch/agent:0.1.3

Then verify that digest, written in place of <digest>:

cosign verify \
  --certificate-identity https://github.com/WireWatch/wirewatch/.github/workflows/agent-release.yml@refs/tags/agent-v0.1.3 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/wirewatch/agent@<digest>

It exits 0 and reports the workflow, the tag and the source commit that built the image.

The digest changes with every release, and the release notes do not print it

The image: line of the release’s agent-k8s.yaml carries the same OCI index digest, and it is the one the Kubernetes route actually pulls.