Olivares AI gobierna los agentes de tu infraestructura, así que su propia cadena de suministro forma parte de tu modelo de confianza. Antes de ejecutar una release, demuestra que es la que publicamos. Cada release incluye los artefactos que necesitas para verificarlo criptográficamente — y la verificación puede ejecutarse sin red alguna, que es la vía para parques desconectados y aislados (air-gapped).
No canalices un instalador hacia un shell. Descarga los artefactos, verifícalos y luego ejecútalos. Los pasos siguientes explican cómo.
Qué incluye una release
Una release etiquetada lleva los archivos binarios más todo lo necesario para atestarlos:
| Artefacto | Qué es |
|---|---|
checksums.txt (+ .sig, .pem) | SHA-256 de cada artefacto, con una firma cosign y un certificado (keyless) |
*_<os>_<arch>.tar.gz | el/los archivo(s) de la release para linux/darwin × amd64/arm64 |
*.spdx.sbom.json / *.cdx.sbom.json | SBOM por archivo, incluido tanto en formato SPDX como CycloneDX |
*.sbom.sigstore.json | el SBOM SPDX envuelto como atestación in-toto firmada sobre el archivo |
*.vex.sigstore.json | una declaración OpenVEX como atestación in-toto firmada sobre el archivo |
*.intoto.jsonl | procedencia de build SLSA (generada por slsa-github-generator) |
| imagen de contenedor | publicada en un registry, firmada y atestada, fijada por digest |
Las atestaciones referencian cada artefacto por sus bytes, nunca por una etiqueta mutable.
La vía de un solo comando
El repositorio incluye scripts/verify-release.sh. Ejecútalo desde el directorio que contiene los ficheros descargados; recorre toda la cadena e informa de cada paso:
# Keyless (Sigstore) — por defecto. Necesita red hacia el log de transparencia (Rekor).
scripts/verify-release.sh
# Basado en clave — verifica contra la clave pública del proyecto (apto para air-gap).
scripts/verify-release.sh --key cosign.pub
# Totalmente sin conexión — basado en clave, sin red al log de transparencia en absoluto.
scripts/verify-release.sh --key cosign.pub --offline
# Fija la procedencia SLSA a una etiqueta de fuente concreta.
scripts/verify-release.sh --source-tag <version>Cómo se usa la red depende del modelo de firma. Las firmas keyless llevan una entrada en el log de transparencia de Rekor, así que la vía por defecto alcanza Rekor (puedes pasar --offline para usar en su lugar una entrada empaquetada). Las firmas basadas en clave se producen sin una entrada en Rekor, así que el script añade --insecure-ignore-tlog y no contacta con nada. La combinación --key cosign.pub --offline es la vía genuinamente desconectada.
El script requiere cosign y sha256sum; slsa-verifier es opcional. Los pasos cuyos artefactos (o cuyo verificador) están ausentes se omiten con una nota clara en lugar de fallar — de modo que funciona en una release mínima y verifica por completo una release completa.
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 keyless 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' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
checksums.txtLa basada en clave usa en su lugar cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.
2. Integridad de los artefactos
Vuelve a calcular el hash de cada artefacto contra el manifiesto ahora confiable:
sha256sum --check checksums.txt3. Atestación SBOM (SPDX)
cosign verify-blob-attestation --type spdxjson \
--bundle <archive>.sbom.sigstore.json --new-bundle-format \
--check-claims <archive>Añade --key cosign.pub --insecure-ignore-tlog (en lugar de los flags de identidad) para la vía sin conexión. El SBOM CycloneDX (*.cdx.sbom.json) se incluye junto a él para herramientas que lo prefieran.
4. Atestación OpenVEX
La declaración de vulnerabilidades del proyecto, verificada de la misma manera:
cosign verify-blob-attestation --type openvex \
--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/olivaresVerificar la imagen de contenedor
La vía keyless 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/controlplane
DIGEST="$(crane digest "$IMAGE:<version>")"
REF="$IMAGE@$DIGEST"
cosign verify "$REF" \
--certificate-identity-regexp '^https://github.com/olivaresai/olivares' \
--certificate-oidc-issuer https://token.actions.githubusercontent.comPara un parque totalmente desconectado, usa en su lugar el bundle de air-gap: lleva la imagen, sus firmas y atestaciones, y un cosign.pub, y verifica sin conexión con cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. La guía de self-host cubre cómo construir y replicar ese bundle.
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 es pre-1.0 y 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.