Verificar uma versão

O Olivares AI governa os agentes na sua infraestrutura, portanto a sua própria cadeia de fornecimento faz parte do seu modelo de confiança. Antes de executar uma versão, prove que é a que publicamos. Cada versão distribui os artefactos necessários para verificar isso criptograficamente — e a verificação pode funcionar sem qualquer rede, que é o caminho para ambientes desconectados e air-gapped.

Não canalize um instalador para um shell. Descarregue os artefactos, verifique-os e depois execute-os. Os passos abaixo explicam como.

Estado pré-lançamento. Ainda não foi publicada nenhuma versão pública — o olivaresai/olivares é publicado com o lançamento, portanto hoje não há artefacto para descarregar nem nada contra o qual executar estes comandos. Este guia documenta a cadeia de verificação que cada versão pública transportará; o pipeline que a sustenta está construído e é exercitado em CI. Tudo o que se segue torna-se executável com a primeira versão etiquetada.

O que acompanha uma versão

Uma versão etiquetada transporta os arquivos binários mais tudo o necessário para os atestar:

As atestações referenciam cada artefacto pelos seus bytes, nunca por uma etiqueta mutável.

O caminho de um comando

O repositório distribui scripts/verify-release.sh. Execute-o a partir do diretório com os ficheiros descarregados; percorre toda a cadeia e reporta cada passo:

# Sem chave (Sigstore) — predefinido. Precisa de rede para o log de transparencia (Rekor).
scripts/verify-release.sh

# Baseado em chave — verifica contra a chave publica do projeto (compativel com air-gap).
scripts/verify-release.sh --key cosign.pub

# Totalmente offline — baseado em chave, sem rede para log de transparencia.
scripts/verify-release.sh --key cosign.pub --offline

# Fixar proveniencia SLSA a uma etiqueta de fonte especifica.
scripts/verify-release.sh --source-tag <version>

Como a rede e usada depende do modelo de assinatura. Assinaturas sem chave transportam uma entrada de log de transparência Rekor, portanto o caminho predefinido alcança Rekor (pode passar --offline para usar uma entrada empacotada). Assinaturas baseadas em chave são produzidas sem entrada Rekor, portanto o script adiciona --insecure-ignore-tlog e não contacta nada. A combinacao --key cosign.pub --offline e o caminho genuinamente desconectado.

O script requer cosign e sha256sum; slsa-verifier e opcional. Passos cujos artefactos (ou cujo verificador) estão ausentes são ignorados com uma nota clara em vez de falhar — portanto funciona numa versão mínima e verifica totalmente uma completa.

O que verifica, passo a passo

Se prefere executar as verificações manualmente, esta e a cadeia. Substitua <archive> por cada *.tar.gz.

1. Assinatura sobre os checksums

Verificar checksums.txt confia transitivamente em cada artefacto nele listado. A verificação sem chave fixa a identidade de assinatura a identidade OIDC do GitHub Actions do projeto:

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

Baseado em chave usa cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Integridade dos artefactos

Re-calcule o hash de cada artefacto contra o manifesto agora confiável:

sha256sum --check checksums.txt

3. Atestação SBOM (SPDX)

cosign verify-blob-attestation --type spdxjson \
  --bundle <archive>.sbom.sigstore.json --new-bundle-format \
  --check-claims <archive>

Adicione --key cosign.pub --insecure-ignore-tlog (em vez das flags de identidade) para o caminho offline. O SBOM CycloneDX (*.cdx.sbom.json) e distribuído ao lado para ferramentas que o preferem.

4. Atestação OpenVEX

A declaracao de vulnerabilidade do projeto, verificada da mesma forma:

cosign verify-blob-attestation --type openvex \
  --bundle <archive>.vex.sigstore.json --new-bundle-format \
  --check-claims <archive>

5. Proveniência SLSA

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

Verificar a imagem de contentor

O caminho sem chave da imagem prova a imagem contra a mesma identidade GitHub Actions mas precisa de rede. Resolva e implante sempre por digest, nunca por uma etiqueta mutável:

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

Para um ambiente totalmente desconectado, use o pacote air-gap: transporta a imagem, as suas assinaturas e atestações, e um cosign.pub, e verifica offline com cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. O guia de auto-hospedagem cobre a construção e espelhamento desse pacote.

O que a verificação prova e não prova

A verificação criptografica prova proveniência e integridade: que o artefacto e o resultado exato e não modificado que o nosso pipeline construiu e assinou. Não certifica o comportamento do software nem qualquer postura de conformidade. O Olivares AI e pre-1.0 e e desenhado para — não certificado contra — frameworks como SOC 2 e ISO 27001; veja Honestidade e limites para o que essa distincao significa na prática.

A verificação também é tão completa quanto as atestações que uma dada versão realmente publicou. O verificador reporta cada passo que executa; se uma build omite um artefacto, o passo correspondente não tem nada para verificar. A versão padrão anexa os artefactos SBOM, OpenVEX e SLSA nomeados acima.