Weryfikacja wydania

Olivares AI zarzadza agentami na twojej infrastrukturze, wiec jego wlasny lancuch dostaw jest czescia twojego modelu zaufania. Zanim uruchomisz wydanie, udowodnij, ze to to, ktore opublikowalismy. Kazde wydanie dostarcza artefakty potrzebne do kryptograficznej weryfikacji — a weryfikacja moze dzialac bez jakiejkolwiek sieci, co jest sciezka dla odlaczonych i izolowanych sieciowo infrastruktur.

Nie podawaj instalatora do shella. Pobierz artefakty, zweryfikuj je, nastepnie uruchom. Kroki ponizej pokazuja jak.

Status pre-release. Zadne publiczne wydanie nie zostalo jeszcze opublikowane — olivaresai/olivares publikuje sie wraz z premiera, wiec dzisiaj nie ma artefaktu do pobrania ani niczego, wobec czego mozna uruchomic te polecenia. Ten przewodnik dokumentuje lancuch weryfikacji, ktory bedzie niesc kazde publiczne wydanie; potok, ktory za nim stoi, jest zbudowany i cwiczony w CI. Wszystko ponizej stanie sie wykonywalne wraz z pierwszym otagowanym wydaniem.

Co jest dostarczane z wydaniem

Otagowane wydanie niesie archiwa binarne plus wszystko potrzebne do ich poswiadczenia:

Atestacje odwoluja sie do kazdego artefaktu po jego bajtach, nigdy po zmiennym tagu.

Sciezka jednego polecenia

Repozytorium dostarcza scripts/verify-release.sh. Uruchom go z katalogu zawierajacego pobrane pliki; przechodzi caly lancuch i raportuje kazdy krok:

# Bezkluczykowy (Sigstore) — domyslny. Wymaga sieci do logu przejrzystosci (Rekor).
scripts/verify-release.sh

# Oparty na kluczu — weryfikuj wobec klucza publicznego projektu (przyjazny air-gap).
scripts/verify-release.sh --key cosign.pub

# W pelni offline — oparty na kluczu, bez sieci do logu przejrzystosci.
scripts/verify-release.sh --key cosign.pub --offline

# Przypnij provenance SLSA do konkretnego tagu zrodlowego.
scripts/verify-release.sh --source-tag <version>

Jak siec jest uzywana zalezy od modelu podpisywania. Podpisy bezkluczykowe niosą wpis logu przejrzystosci Rekor, wiec domyslna sciezka siega do Rekor (mozesz przekazac --offline by uzyc dolaczonego wpisu zamiast tego). Podpisy oparte na kluczu sa produkowane bez wpisu Rekor, wiec skrypt dodaje --insecure-ignore-tlog i nie kontaktuje niczego. Kombinacja --key cosign.pub --offline to prawdziwie odlaczona sciezka.

Skrypt wymaga cosign i sha256sum; slsa-verifier jest opcjonalny. Kroki, ktorych artefakty (lub weryfikator) sa nieobecne, sa pomijane z wyrazna notatka zamiast byc bledne — wiec dziala na minimalnym wydaniu i w pelni weryfikuje kompletne.

Co sprawdza, krok po kroku

Jesli wolisz uruchomić sprawdzenia recznie, oto lancuch. Podstaw <archive> za kazdy *.tar.gz.

1. Podpis nad sumami kontrolnymi

Weryfikacja checksums.txt tranzytywnie ufa kazdemu artefaktowi wymienionemu w nim. Weryfikacja bezkluczykowa przypina tozsamosc podpisujacego do tozsamosci OIDC GitHub Actions projektu:

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

Oparta na kluczu zamiast tego uzywa cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Integralnosc artefaktu

Ponownie oblicz hash kazdego artefaktu wobec teraz zaufanego manifestu:

sha256sum --check checksums.txt

3. Atestacja SBOM (SPDX)

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

Dodaj --key cosign.pub --insecure-ignore-tlog (zamiast flag tozsamosci) dla sciezki offline. SBOM CycloneDX (*.cdx.sbom.json) jest dostarczany obok dla narzedzi, ktore go preferuja.

4. Atestacja OpenVEX

Oswiadczenie o podatnosciach projektu, weryfikowane w ten sam sposob:

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

5. Provenance SLSA

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

Weryfikacja obrazu kontenera

Bezkluczykowa sciezka obrazu udowadnia obraz wobec tej samej tozsamosci GitHub Actions, ale wymaga sieci. Zawsze rozwiazuj i wdrazaj po digest, nigdy po zmiennym tagu:

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

Dla w pelni odlaczonej infrastruktury uzyj pakietu air-gap zamiast tego: niesie obraz, jego podpisy i atestacje oraz cosign.pub, i weryfikuje offline z cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. Przewodnik self-host obejmuje budowanie i mirrorowanie tego pakietu.

Co weryfikacja udowadnia a czego nie

Weryfikacja kryptograficzna udowadnia provenance i integralnosc: ze artefakt jest dokladnym, niezmodyfikowanym wynikiem naszego potoku budowy i podpisania. Nie certyfikuje zachowania oprogramowania ani jakiejkolwiek postawy zgodnosci. Olivares AI jest pre-1.0 i jest projektowany w kierunku — nie certyfikowany wobec — frameworkow takich jak SOC 2 i ISO 27001; zobacz Uczciwosci i ograniczenia co to rozroznienie oznacza w praktyce.

Weryfikacja jest rowniez tak kompletna jak atestacje, ktore dane wydanie faktycznie opublikowalo. Weryfikator raportuje kazdy krok, ktory uruchamia; jesli budowa pomija artefakt, odpowiedni krok nie ma nic do sprawdzenia. Standardowe wydanie dolacza artefakty SBOM, OpenVEX i SLSA wymienione powyzej.