Verificar uma versão

Descarregue os artefactos e verifique as assinaturas, checksums e atestações antes da instalação. Use a identidade de assinatura e a etiqueta da versão descarregada. Os requisitos de rede estão descritos abaixo.

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

A próxima versão é 1.0, a primeira versão estável de Community e Business/Enterprise. Ainda não foi publicada. As capacidades e os seus limites atuais estão documentados separadamente. Honestidade e limites.

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

Obtenha scripts/verify-release.sh num checkout de confiança do código no tag da versão; não é um ficheiro da release. Executá-lo implica confiar nesse checkout. Use o seu caminho a partir da pasta dos ficheiros descarregados; indica cada passo de verificação.

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

--offline elimina a consulta a Rekor das chamadas cosign; não torna toda a verificação independente da rede. A verificação sem chave precisa das raízes de confiança Sigstore, descarregadas se não estiverem em cache. O script não tem a opção --trusted-root. Os bundles SBOM e OpenVEX precisam de uma raiz de confiança mesmo com --key; o passo SLSA executa slsa-verifier sem opção offline. As versões públicas são assinadas sem chave e não publicam uma chave de verificação. Use --key apenas para ficheiros assinados com uma chave cuja parte pública recebeu do proprietário por um canal diferente do dos ficheiros a verificar.

O script requer cosign e sha256sum. Em modo consumidor indica como ignorados os passos sem atestações ou sem slsa-verifier. Um passo ignorado não está verificado. O modo --strict-publication, apenas para quem publica, também exige --cert-identity e --source-uri; rejeita --key e --offline.

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

2. Integridade dos artefactos

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

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

3. Atestação 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. Atestação OpenVEX

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

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. 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

Num ambiente isolado da rede

Um operador cria o pacote air-gap com uma chave cosign que controla. O pacote inclui o respetivo cosign.pub; os scripts verificam o chart Helm e as imagens guardadas com essa chave, sem Rekor. Antes de confiar no pacote, compare a chave pública com uma cópia recebida do proprietário por outro canal. Uma chave dentro do pacote não autentica o próprio pacote. Uma imagem só passa a verificação se tiver uma assinatura feita com essa chave.

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

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 é 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.