Verificación de artefactos de la versión

ZeroClaw utiliza las atestaciones de artefactos de GitHub como mecanismo de procedencia canónico para los recursos de versión descargables. Cada atestación correcta registra el resumen del recurso, la confirmación de origen y la identidad del flujo de trabajo de versión como procedencia SLSA v1.0 Build Level 2.

La atestación demuestra dónde y cómo se compiló un artefacto. No demuestra que una persona haya revisado el código fuente, que las dependencias sean seguras, ni que no se haya comprometido una cuenta de mantenedor, un runner alojado en GitHub o el plano de control de GitHub. Consulta docs/security/slsa-provenance.md en el repositorio para ver el modelo de amenazas completo.

El flujo de trabajo de lanzamiento trata actualmente las atestaciones como salida de Fase A de mejor esfuerzo. Verifique las notas de lanzamiento antes de depender del material de verificación; estas indican si se produjo la procedencia en línea y el archivo sin conexión.

Verificación en línea

Instala el CLI de GitHub, descarga un recurso y verifícalo con el flujo de trabajo de lanzamiento y el commit de origen:

VERSION=vX.Y.Z
SOURCE_DIGEST=<40-character-release-commit>
ASSET=zeroclaw-x86_64-unknown-linux-gnu.tar.gz

gh release download "$VERSION" --repo zeroclaw-labs/zeroclaw \
  --pattern "$ASSET"
gh attestation verify "$ASSET" \
  --repo zeroclaw-labs/zeroclaw \
  --signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
  --source-digest "$SOURCE_DIGEST"

Use el commit completo mostrado para la etiqueta de la versión. Un comando exitoso imprime la atestación verificada y el resumen del sujeto. El mismo comando se aplica a install.sh, SHA256SUMS, ambos archivos SBOM y el archivo de verificación.

Verificación sin conexión

Una versión producida por el flujo de trabajo consolidado con la salida completa de la Fase A publica un único archivo comprimido llamado zeroclaw-vX.Y.Z-verification.tar.gz. Contiene:

un paquete <artifact>.attestation.jsonl por cada carga útil de lanzamiento;
trusted_root.jsonl, el material de raíz de confianza de GitHub y Sigstore;
ATTESTATION-BUNDLES.md, un índice de nombres de artefactos, resúmenes SHA-256 y nombres de paquetes.

El archivo no puede contener su propia attestation sin crear un digest circular. Establezca la confianza inicial mientras esté conectado verificando el archivo, el archive y el archivo de checksum final en línea. Luego transfiera el artefacto, el archive y el archivo de checksum al entorno sin conexión.

Paso de staging conectado

VERSION=vX.Y.Z
SOURCE_DIGEST=<40-character-release-commit>
ASSET=zeroclaw-x86_64-unknown-linux-gnu.tar.gz
VERIFY_ARCHIVE=zeroclaw-${VERSION}-verification.tar.gz

gh release download "$VERSION" --repo zeroclaw-labs/zeroclaw \
  --pattern "$ASSET" \
  --pattern SHA256SUMS \
  --pattern "$VERIFY_ARCHIVE"

gh attestation verify "$VERIFY_ARCHIVE" \
  --repo zeroclaw-labs/zeroclaw \
  --signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
  --source-digest "$SOURCE_DIGEST"
gh attestation verify SHA256SUMS \
  --repo zeroclaw-labs/zeroclaw \
  --signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
  --source-digest "$SOURCE_DIGEST"

awk -v file="$VERIFY_ARCHIVE" '$2 == file { print }' SHA256SUMS | sha256sum -c -
mkdir verification
tar -xzf "$VERIFY_ARCHIVE" -C verification

Además, compara el resumen del artefacto con su fila en SHA256SUMS antes de la transferencia:

awk -v file="$ASSET" '$2 == file { print }' SHA256SUMS | sha256sum -c -

Paso de verificación sin conexión

No se requiere ninguna solicitud de red cuando tanto --bundle como --custom-trusted-root apuntan al material de verificación preparado:

gh attestation verify "$ASSET" \
  --repo zeroclaw-labs/zeroclaw \
  --signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
  --source-digest "$SOURCE_DIGEST" \
  --bundle "verification/${ASSET}.attestation.jsonl" \
  --custom-trusted-root verification/trusted_root.jsonl

SHA256SUMS y el archivo de verificación son metadatos de arranque en línea y no tienen paquetes dentro del archivo. Todos los payloads presentes antes de que se construya el archivo, incluidos install.sh y ambos SBOMs, sí los tienen.

SBOMs

Se publican dos archivos SBOM con suma de verificación y certificación en cada versión:

Archivo	Formato
`zeroclaw-vX.Y.Z-sbom.spdx.json`	SPDX JSON
`zeroclaw-vX.Y.Z-sbom.cdx.json`	CycloneDX JSON

Verifica cualquiera de los dos SBOM con el mismo comando de atestación en línea o sin conexión utilizado para un recurso binario. Herramientas como Syft o Grype pueden inspeccionar entonces el archivo verificado.

Imágenes de contenedor

Las imágenes de contenedor de GHCR siguen firmadas por digest con cosign. Esto es independiente de la ruta de atestación de GitHub para los recursos de release descargables.

IMAGE=ghcr.io/zeroclaw-labs/zeroclaw
TAG=vX.Y.Z

cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp "^https://github.com/zeroclaw-labs/zeroclaw/" \
  "${IMAGE}:${TAG}"

Para despliegues fijados, resuelve el digest y verifica ${IMAGE}@${DIGEST} en lugar de una etiqueta mutable.

Keyboard shortcuts