Ein Release überprüfen

Seit 0.9.0 wird alles, was ein Release veröffentlicht, vom Release-Workflow des Repositorys (.github/workflows/release.yml) mit keyless-Signierung über Sigstore signiert oder attestiert. Es gibt keinen langlebigen Signierschlüssel, den man beschaffen, schützen oder rotieren müsste: Die Signaturidentität ist der GitHub-Actions-Workflow selbst, festgehalten in einem kurzlebigen Zertifikat und im öffentlichen Sigstore-Transparenzlog. Überprüfen heißt prüfen, dass das Artefakt von diesem Workflow gebaut wurde, aus einem v*-Tag von laupernoe/dumbmonit.

Agent-Binaries

Jedes Binary auf dem GitHub-Release kommt mit <file>.sigstore.json (dem Signaturbündel) und <file>.sha256, und das Release trägt dumbmonit-agent.intoto.jsonl, die SLSA-Build-Provenance.

cosign verify-blob dumbmonit-agent-linux-x86_64 \
  --bundle dumbmonit-agent-linux-x86_64.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/laupernoe/dumbmonit/\.github/workflows/release\.yml@refs/tags/v'

# or, with the GitHub CLI (checks the provenance attestation)
gh attestation verify dumbmonit-agent-linux-x86_64 -R laupernoe/dumbmonit

# or against the provenance attached to the release
gh attestation verify dumbmonit-agent-linux-x86_64 -R laupernoe/dumbmonit \
  --bundle dumbmonit-agent.intoto.jsonl

Ein erfolgreicher Lauf gibt die Workflow-Identität und den Tag aus. Schlägt er fehl, installieren Sie die Datei nicht und melden Sie es.

Container-Images

Das Server- und das Agent-Image tragen eine nach ghcr.io gepushte Build-Provenance-Attestierung sowie eine SPDX-SBOM und eine vollständige SLSA-Provenance am Image-Index.

gh attestation verify oci://ghcr.io/laupernoe/dumbmonit:0.9.0 -R laupernoe/dumbmonit

# the SBOM and the provenance recorded by the build
docker buildx imagetools inspect ghcr.io/laupernoe/dumbmonit:0.9.0 \
  --format '{{ json .SBOM }}'
docker buildx imagetools inspect ghcr.io/laupernoe/dumbmonit:0.9.0 \
  --format '{{ json .Provenance }}'

Fixieren Sie ein Image in Ihrer Compose-Datei per Digest, wenn das, was Sie überprüft haben, genau das sein soll, was läuft.

Nachträglich signiert

Releases vor 0.9.0 (v0.1.0-alpha.N) und Dateien, die der Release-Workflow nicht selbst signiert hat (etwa provenance.json), erhalten ihre <Datei>.sigstore.json von einem eigenen, von Hand gestarteten Workflow (.github/workflows/sign-releases.yml). Seine Signatur besagt nur, dass die Datei zum Zeitpunkt dieses Laufs im Release lag, nicht, dass sie aus dem Tag gebaut wurde: Prüfen Sie sie gegen die Identität dieses Workflows und vergleichen Sie die Datei mit der zugehörigen .sha256.

cosign verify-blob dumbmonit-agent-linux-x86_64 \
  --bundle dumbmonit-agent-linux-x86_64.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/laupernoe/dumbmonit/\.github/workflows/sign-releases\.yml@refs/heads/(main|dev)$'

Diese Releases haben keine Build-Provenance: gh attestation verify gilt für sie nicht.

Versions-Tags

Release-Tags (v0.9.0, …) sind annotiert, nicht GPG-signiert, und nur Repository-Administratoren können sie erstellen (ein Ruleset reserviert v*). Das Vertrauen in ein Release beruht auf den signierten Artefakten oben, deren Zertifikat den Tag nennt, aus dem sie gebaut wurden, und nicht auf der Tag-Signatur.