Verify Your Drydock Install

Every Drydock release is signed with cosign (keyless, via the Sigstore public-good infrastructure) and ships with SLSA build provenance attestations generated inside GitHub Actions. You can — and should — verify both before running the image or extracting the archive.

The examples on this page use v1.5.2 as a placeholder. Replace it with the tag you're verifying.

What you need

Everything is keyless — you do NOT need a Drydock-specific public key. Sigstore and GitHub's attestation framework use short-lived certificates tied to the release workflow's OIDC identity.

Verify container images

The release workflow signs every pushed tag (ghcr.io, docker.io, quay.io) with the same identity. Use this policy to verify:

TAG="v1.5.2"
VERSION="${TAG#v}"
IMAGE="ghcr.io/codeswhat/drydock:${VERSION}"
IDENTITY_REGEX='^https://github.com/CodesWhat/drydock/.github/workflows/release-cut.yml@refs/heads/main$'
OIDC_ISSUER='https://token.actions.githubusercontent.com'

cosign verify \
  --certificate-identity-regexp "${IDENTITY_REGEX}" \
  --certificate-oidc-issuer "${OIDC_ISSUER}" \
  "${IMAGE}"

Swap IMAGE for any of the three registries we publish to:

IMAGE="ghcr.io/codeswhat/drydock:1.5.2"

IMAGE="docker.io/codeswhat/drydock:1.5.2"

IMAGE="quay.io/codeswhat/drydock:1.5.2"

A successful verification prints the signature payload and exits 0. Any other outcome — failure, missing signature, identity mismatch — means do not run the image.

Verify image provenance (SLSA)

The container image also carries a signed SLSA provenance attestation published to the registry. Verify it with the GitHub CLI:

gh attestation verify \
  oci://ghcr.io/codeswhat/drydock:1.5.2 \
  --repo CodesWhat/drydock \
  --signer-workflow CodesWhat/drydock/.github/workflows/release-cut.yml

gh confirms that the image digest has a valid attestation from CodesWhat/drydock's release-cut.yml workflow. This command does not bind the image to the release tag; the tarball provenance check below performs the tag-bound verification.

Verify the release tarball

Each GitHub release includes six files for the source archive:

1. Download

TAG="v1.5.2"
BASE_URL="https://github.com/CodesWhat/drydock/releases/download/${TAG}"
ARCHIVE="drydock-${TAG}.tar.gz"

curl -fsSLO "${BASE_URL}/${ARCHIVE}"
curl -fsSLO "${BASE_URL}/${ARCHIVE}.sha256"
curl -fsSLO "${BASE_URL}/${ARCHIVE}.sig"
curl -fsSLO "${BASE_URL}/${ARCHIVE}.pem"
curl -fsSLO "${BASE_URL}/${ARCHIVE}.bundle"
curl -fsSLO "${BASE_URL}/${ARCHIVE}.intoto.jsonl"

2. Check the SHA-256

Fast integrity check. Doesn't prove authenticity — only that the bytes match what's on the release page.

sha256sum --check "${ARCHIVE}.sha256"
# drydock-v1.5.2.tar.gz: OK

On macOS, use shasum -a 256 -c "${ARCHIVE}.sha256".

3. Verify the cosign signature

This proves the tarball was signed by the Drydock release workflow at this tag.

IDENTITY_REGEX='^https://github.com/CodesWhat/drydock/.github/workflows/release-cut.yml@refs/heads/main$'
OIDC_ISSUER='https://token.actions.githubusercontent.com'

cosign verify-blob \
  --signature "${ARCHIVE}.sig" \
  --certificate "${ARCHIVE}.pem" \
  --certificate-identity-regexp "${IDENTITY_REGEX}" \
  --certificate-oidc-issuer "${OIDC_ISSUER}" \
  "${ARCHIVE}"
# Verified OK

4. Verify the SLSA provenance

The .intoto.jsonl file is a signed in-toto attestation describing how, when, and where the tarball was built. Two ways to verify:

gh attestation verify "${ARCHIVE}" \
  --repo CodesWhat/drydock \
  --signer-workflow CodesWhat/drydock/.github/workflows/release-cut.yml

slsa-verifier verify-artifact \
  --provenance-path "${ARCHIVE}.intoto.jsonl" \
  --source-uri github.com/CodesWhat/drydock \
  --source-tag "${TAG}" \
  "${ARCHIVE}"

Passing both the cosign signature and the SLSA attestation confirms the tarball came from the release workflow, on this tag, and has not been modified.

Why some older tags look different

The Drydock release pipeline has been reshaped twice. Signatures embed the workflow file + ref that produced them, so the identity regex depends on which version of the pipeline signed the tag you're verifying:

# v1.5.0-rc.11 and newer (tag-last pipeline, signed by release-cut.yml on main):
IDENTITY_REGEX='^https://github.com/CodesWhat/drydock/.github/workflows/release-cut.yml@refs/heads/main$'

# v1.5.0-rc.1 through v1.5.0-rc.10 (tag-triggered pipeline, signed by release-from-tag.yml on the tag):
IDENTITY_REGEX='^https://github.com/CodesWhat/drydock/.github/workflows/release-from-tag.yml@refs/tags/.+$'

# v1.4.x and older (signed by release.yml):
IDENTITY_REGEX='^https://github.com/CodesWhat/drydock/.github/workflows/release.yml@refs/(heads/main|tags/.+)$'

The v1.5.0-rc.11 switchover moved image and artifact signing to happen before the git tag is pushed, so that a published tag always corresponds to a live, signed image. The old tag-triggered pipeline could produce a visible git tag without a corresponding signed image if the registry push failed mid-flight (see discussion #306).

Some older image tags also expose legacy sha256-<digest>.sig tags in registries. Newer releases store signatures via OCI referrers instead, so you may not see a .sig tag in the registry even though cosign verify succeeds.

See also

• Security Hardening Guide — lock down a running Drydock deployment
• Update Bouncer — use Drydock's built-in cosign support to verify the images Drydock itself is watching
• Sigstore documentation — background on keyless signing and Rekor transparency log
• SLSA framework — what the provenance attestation proves