Weryfikacja wydania

Pobierz artefakty wydania i przed instalacją zweryfikuj podpisy, sumy kontrolne i atestacje. Użyj tożsamości podpisującego i tagu pobranej wersji. Wymagania sieciowe opisano poniżej.

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

Następna wersja to 1.0, pierwsza stabilna wersja Community i Business/Enterprise. Nie została jeszcze wydana. Funkcje i ich obecne ograniczenia opisano osobno. Uczciwość i ograniczenia.

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.

Ścieżka jednego polecenia

Pobierz scripts/verify-release.sh z zaufanej kopii kodu źródłowego na tagu wydania; skrypt nie jest plikiem wydania. Uruchomienie oznacza zaufanie do tej kopii. Podaj ścieżkę do skryptu z katalogu pobranych plików; raportuje wynik każdego kroku weryfikacji.

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

--offline usuwa odwołanie do Rekor z wywołań cosign, ale nie sprawia, że cała weryfikacja działa bez sieci. Weryfikacja bez klucza wymaga korzeni zaufania Sigstore, pobieranych, jeśli nie ma ich w pamięci podręcznej. Skrypt nie ma opcji --trusted-root. Pakiety SBOM i OpenVEX wymagają korzenia zaufania nawet z --key; krok SLSA uruchamia slsa-verifier bez opcji offline. Publiczne wydania są podpisywane bez klucza i nie publikują klucza weryfikacyjnego. Używaj --key tylko dla plików, których publiczny klucz podpisu otrzymano od właściciela kanałem innym niż kanał dostarczenia weryfikowanych plików.

Skrypt wymaga cosign i sha256sum. W trybie użytkownika zgłasza brak atestacji lub slsa-verifier jako pominięte kroki. Pominięty krok nie jest zweryfikowany. Tryb --strict-publication, przeznaczony tylko dla wydawcy, wymaga również --cert-identity i --source-uri; odrzuca --key i --offline.

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 bez klucza 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

2. Integralnosc artefaktu

Ponownie oblicz hash kazdego artefaktu wobec teraz zaufanego manifestu:

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

3. Atestacja 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. Atestacja OpenVEX

Oswiadczenie o podatnosciach projektu, weryfikowane w ten sam sposob:

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

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

Weryfikacja obrazu kontenera

Ścieżka obrazu podpisanego bez klucza 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

W środowisku odizolowanym od sieci

Operator tworzy pakiet air-gap z kluczem cosign, który kontroluje. Pakiet zawiera odpowiedni cosign.pub; skrypty sprawdzają chart Helm i zapisane obrazy tym kluczem bez Rekor. Zanim zaufasz pakietowi, porównaj klucz publiczny z kopią otrzymaną od właściciela osobnym kanałem. Klucz wewnątrz pakietu nie potwierdza autentyczności samego pakietu. Obraz przechodzi weryfikację tylko wtedy, gdy zawiera podpis utworzony tym kluczem.

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

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 projektowany w kierunku — nie certyfikowany wobec — frameworkow takich jak SOC 2 i ISO 27001; zobacz Uczciwość 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.