릴리스 검증

릴리스 아티팩트를 다운로드하고 설치 전에 서명, 체크섬, 증명을 검증하세요. 다운로드한 버전의 서명 ID와 태그를 사용하세요. 네트워크 요구 사항은 아래에 설명되어 있습니다.

설치 프로그램을 셸에 파이프하지 마세요. 아티팩트를 다운로드하고, 검증한 다음 실행하세요. 아래 단계가 그 방법입니다.

다음 버전은 Community와 Business/Enterprise의 첫 안정 버전인 1.0입니다. 아직 출시되지 않았습니다. 기능과 현재의 제한 사항은 별도로 문서화되어 있습니다. 정직함 & 한계.

릴리스와 함께 제공되는 것

태그된 릴리스는 바이너리 아카이브와 이를 증명하는 데 필요한 모든 것을 포함합니다:

증명은 변경 가능한 태그가 아닌 바이트로 각 아티팩트를 참조합니다.

한 명령 경로

scripts/verify-release.sh는 릴리스 태그의 신뢰할 수 있는 소스 코드 체크아웃에서 가져오세요. 릴리스 파일에 포함되지 않습니다. 실행하면 그 체크아웃을 신뢰하는 것입니다. 다운로드한 파일의 디렉터리에서 스크립트 경로를 지정해 실행하면 각 검증 단계의 결과를 보고합니다.

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

--offline은 cosign 호출의 Rekor 조회를 제거할 뿐 전체 검증을 네트워크 없이 실행하게 하지는 않습니다. 키 없는 검증에는 Sigstore 신뢰 루트가 필요하며 캐시가 없으면 가져옵니다. 스크립트에는 --trusted-root 옵션이 없습니다. SBOM과 OpenVEX 번들 검증은 --key를 사용해도 신뢰 루트가 필요합니다. SLSA 단계는 오프라인 옵션 없이 slsa-verifier를 실행합니다. 공개 릴리스는 키 없는 서명을 사용하며 검증 키를 배포하지 않습니다. --key는 검증할 파일과 다른 경로로 키 소유자에게서 공개 키를 받은, 해당 키로 서명된 파일에만 사용하세요.

스크립트에는 cosign과 sha256sum이 필요합니다. 소비자 모드에서는 증명이나 slsa-verifier가 없는 단계를 건너뛴 것으로 보고합니다. 건너뛴 단계는 검증되지 않았습니다. 게시자 전용 --strict-publication 모드에는 --cert-identity와 --source-uri도 필요하며 --key와 --offline은 거부합니다.

확인 사항, 단계별

수동으로 검사를 실행하려면 이것이 체인입니다. <archive>를 각 *.tar.gz로 대체하세요.

1. 체크섬에 대한 서명

checksums.txt를 검증하면 그 안에 나열된 모든 아티팩트를 전이적으로 신뢰합니다. 키 없는 검증은 서명 신원을 프로젝트의 GitHub Actions OIDC 신원에 고정합니다:

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. 아티팩트 무결성

이제 신뢰할 수 있는 매니페스트에 대해 모든 아티팩트의 해시를 재계산합니다:

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

3. 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. OpenVEX 증명

프로젝트의 취약점 선언, 동일한 방식으로 검증:

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. 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 키로 에어갭 번들을 만듭니다. 번들에는 해당 cosign.pub가 포함되며, 스크립트는 Rekor 없이 그 키로 Helm 차트와 저장된 이미지를 검증합니다. 번들을 신뢰하기 전에 다른 경로로 키 소유자에게서 받은 공개 키와 비교하세요. 번들 안의 키만으로는 그 번들 자체를 인증할 수 없습니다. 이미지는 해당 키로 만든 서명이 있어야만 검증을 통과합니다.

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

검증이 증명하는 것과 증명하지 않는 것

암호학적 검증은 출처와 무결성을 증명합니다: 아티팩트가 파이프라인이 빌드하고 서명한 정확하고 수정되지 않은 출력임을. 소프트웨어의 동작이나 준수 자세를 인증하지 않습니다. Olivares AI는 SOC 2 및 ISO 27001과 같은 프레임워크 방향으로 설계되었지만 인증된 것은 아닙니다; 그 구분이 실제로 무엇을 의미하는지는 정직함 & 한계를 참조하세요.

검증은 또한 주어진 릴리스가 실제로 게시한 증명만큼만 완전합니다. 검증기는 실행하는 각 단계를 보고합니다; 빌드가 아티팩트를 생략하면 해당 단계에는 확인할 것이 없습니다. 표준 릴리스는 위에 명명된 SBOM, OpenVEX, SLSA 아티팩트를 첨부합니다.