Verificar una release

Descarga los artefactos de la versión y verifica sus firmas, sumas de comprobación y atestaciones antes de instalar. Usa la identidad de firma y la etiqueta de la versión descargada. La verificación tiene los requisitos de red que se explican abajo.

No canalices un instalador hacia un shell. Descarga los artefactos, verifícalos y luego ejecútalos. Los pasos siguientes explican cómo.

La próxima versión es 1.0, la primera versión estable de Community y Business/Enterprise. Aún no se ha publicado. Las capacidades y sus límites actuales se documentan por separado. Honestidad y límites.

Qué incluye una release

Una release etiquetada lleva los archivos binarios más todo lo necesario para atestarlos:

Las atestaciones referencian cada artefacto por sus bytes, nunca por una etiqueta mutable.

La vía de un solo comando

Obtén scripts/verify-release.sh de un checkout de confianza del código del tag de la versión; no es un archivo de release. Al ejecutarlo confías en ese checkout. Usa su ruta desde la carpeta de los archivos descargados; informa de cada paso de verificación.

/path/to/olivares/scripts/verify-release.sh --source-tag <version>

--offline elimina la consulta a Rekor de las llamadas a cosign; no convierte toda la verificación en un proceso sin red. La verificación sin clave necesita material de raíz de confianza de Sigstore, que se descarga salvo que esté en caché. El script no tiene la opción --trusted-root. Las comprobaciones de paquetes SBOM y OpenVEX necesitan una raíz de confianza incluso con --key; el paso SLSA ejecuta slsa-verifier sin opción offline. Las versiones públicas se firman sin clave y no publican una clave de verificación. Usa --key solo para archivos firmados con una clave cuya parte pública hayas obtenido de su propietario por un canal distinto al de los archivos que verificas.

El script requiere cosign y sha256sum. En modo consumidor indica como omitidos los pasos sin atestaciones o sin slsa-verifier. Un paso omitido no está verificado. El modo --strict-publication, solo para quien publica, también exige --cert-identity y --source-uri; rechaza --key y --offline.

Qué comprueba, paso a paso

Si prefieres ejecutar las comprobaciones a mano, esta es la cadena. Sustituye <archive> por cada *.tar.gz.

1. Firma sobre los checksums

Verificar checksums.txt confía transitivamente en cada artefacto listado en él. La verificación sin clave fija la identidad de firma a la identidad OIDC de GitHub Actions del proyecto:

cosign verify-blob \
  --certificate checksums.txt.pem \
  --signature checksums.txt.sig \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt

2. Integridad de los artefactos

Vuelve a calcular el hash de cada artefacto contra el manifiesto ahora confiable:

sha256sum --ignore-missing --check checksums.txt

3. Atestación SBOM (SPDX)

cosign verify-blob-attestation --type spdxjson \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle <archive>.sbom.sigstore.json --new-bundle-format \
  --check-claims <archive>

4. Atestación OpenVEX

La declaración de vulnerabilidades del proyecto, verificada de la misma manera:

cosign verify-blob-attestation --type openvex \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle <archive>.vex.sigstore.json --new-bundle-format \
  --check-claims <archive>

5. Procedencia SLSA

slsa-verifier verify-artifact <archive> \
  --provenance-path <provenance>.intoto.jsonl \
  --source-uri github.com/olivaresai/olivares

Verificar la imagen de contenedor

La vía sin clave para la imagen demuestra la imagen contra la misma identidad de GitHub Actions, pero necesita red. Resuelve y despliega siempre por digest, nunca por una etiqueta mutable:

IMAGE=ghcr.io/olivaresai/olivares
DIGEST="$(crane digest "$IMAGE:<version>")"
REF="$IMAGE@$DIGEST"

cosign verify "$REF" \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

En un entorno aislado de la red

Un operador genera el paquete air-gap con una clave cosign que controla. El paquete incluye su cosign.pub; los scripts comprueban el chart de Helm y las imágenes guardadas con esa clave, sin Rekor. Antes de confiar en el paquete, compara su clave pública con una copia recibida del propietario de la clave por otro canal. Una clave dentro del paquete no autentica el paquete que la contiene. Una imagen solo supera la verificación si lleva una firma creada con esa clave.

for d in images/*/; do
  cosign verify --local-image "$d" --insecure-ignore-tlog --key cosign.pub
done
cosign verify-blob --key cosign.pub --insecure-ignore-tlog --signature chart/*.tgz.sig chart/*.tgz

Qué demuestra y qué no demuestra la verificación

La verificación criptográfica demuestra procedencia e integridad: que el artefacto es la salida exacta y sin modificar que nuestro pipeline construyó y firmó. No certifica el comportamiento del software ni ninguna postura de cumplimiento. Olivares AI está diseñado hacia — no certificado contra — frameworks como SOC 2 e ISO 27001; consulta Honestidad y límites para saber qué significa esa distinción en la práctica.

La verificación también es solo tan completa como las atestaciones que una release dada haya publicado realmente. El verificador informa de cada paso que ejecuta; si un build omite un artefacto, el paso correspondiente no tiene nada que comprobar. La release estándar adjunta los artefactos SBOM, OpenVEX y SLSA nombrados arriba.