Перевірка релізу

Olivares AI керує агентами на вашій інфраструктурі, тому його власний ланцюг постачання є частиною вашої моделі довіри. Перед запуском релізу доведіть, що це той, який ми опублікували. Кожен реліз поставляє артефакти, необхідні для криптографічної перевірки — і перевірка може виконуватися зовсім без мережі, що є шляхом для відключених та ізольованих середовищ.

Не передавайте інсталятор через pipe в shell. Завантажте артефакти, перевірте їх, потім запускайте. Кроки нижче показують як.

Статус pre-release. Жодного публічного релізу ще не опубліковано — olivaresai/olivares публікується разом із запуском, тому сьогодні немає артефакту для завантаження і немає нічого, проти чого можна виконати ці команди. Цей посібник документує ланцюг перевірки, який нестиме кожен публічний реліз; конвеєр, що його забезпечує, побудований і виконується в CI. Усе, що нижче, стане виконуваним із першим міченим релізом.

Що поставляється з релізом

Мічений реліз несе бінарні архіви плюс все необхідне для їх атестації:

Атестації посилаються на кожен артефакт за його байтами, ніколи за мутабельним тегом.

Шлях однією командою

Репозиторій поставляє scripts/verify-release.sh. Запустіть його з каталогу із завантаженими файлами; він проходить весь ланцюг та повідомляє про кожен крок:

# Безключовий (Sigstore) — за замовчуванням. Потребує мережу до журналу прозорості (Rekor).
scripts/verify-release.sh

# На основі ключа — перевірка проти публічного ключа проекту (дружній до ізоляції).
scripts/verify-release.sh --key cosign.pub

# Повністю офлайн — на основі ключа, без мережі журналу прозорості взагалі.
scripts/verify-release.sh --key cosign.pub --offline

# Прив'язка провенансу SLSA до конкретного тегу вихідного коду.
scripts/verify-release.sh --source-tag <version>

Використання мережі залежить від моделі підписання. Безключові підписи несуть запис журналу прозорості Rekor, тому шлях за замовчуванням звертається до Rekor (ви можете передати --offline для використання вбудованого запису). Підписи на основі ключів створюються без запису Rekor, тому скрипт додає --insecure-ignore-tlog і нікуди не звертається. Комбінація --key cosign.pub --offline є справді відключеним шляхом.

Скрипт вимагає cosign та sha256sum; slsa-verifier є опціональним. Кроки, чиї артефакти (або чий верифікатор) відсутні, пропускаються з чітким зазначенням, а не з помилкою — тому він працює на мінімальному релізі та повністю перевіряє повний.

Що перевіряється, крок за кроком

Якщо ви хочете виконати перевірки вручну, ось ланцюг. Замініть <archive> на кожен *.tar.gz.

1. Підпис над контрольними сумами

Перевірка checksums.txt транзитивно довіряє кожному артефакту, переліченому в ньому. Безключова перевірка прив’язує ідентичність підписання до OIDC ідентичності GitHub Actions проекту:

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

На основі ключа замість цього використовує cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Цілісність артефактів

Перерахуйте хеш кожного артефакту проти тепер довіреного маніфесту:

sha256sum --check checksums.txt

3. Атестація SBOM (SPDX)

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

Додайте --key cosign.pub --insecure-ignore-tlog (замість прапорців ідентичності) для офлайн шляху. CycloneDX SBOM (*.cdx.sbom.json) поставляється поруч для інструментів, які його обирають.

4. Атестація OpenVEX

Заява про вразливості проекту, перевірена тим же способом:

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

5. Провенанс SLSA

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

Перевірка образу контейнера

Безключовий шлях для образу доводить образ проти тієї ж ідентичності GitHub Actions, але потребує мережу. Завжди визначайте та розгортайте за дайджестом, ніколи за мутабельним тегом:

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

Для повністю відключеного середовища використовуйте пакет для ізоляції: він несе образ, його підписи та атестації, і cosign.pub, та перевіряється офлайн з cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. Посібник самостійне розгортання описує збірку та дзеркалювання цього пакета.

Що перевірка доводить і не доводить

Криптографічна перевірка доводить провенанс та цілісність: що артефакт є точним, незміненим результатом, який наш конвеєр зібрав та підписав. Вона не сертифікує поведінку програмного забезпечення чи будь-яку позицію відповідності. Olivares AI в стадії до 1.0 та розроблений відповідно до — не сертифікований проти — фреймворків як SOC 2 та ISO 27001; див. Чесність і обмеження для того, що ця відмінність означає на практиці.

Перевірка також настільки повна, наскільки атестації, які фактично опублікував даний реліз. Верифікатор повідомляє про кожен крок, який він виконує; якщо збірка пропустила артефакт, відповідний крок не має чого перевіряти. Стандартний реліз додає артефакти SBOM, OpenVEX та SLSA, названі вище.