验证发布版本

下载发布文件，并在安装前验证签名、校验和及证明。使用所下载版本的签名身份和标签。网络要求见下文。

不要将安装程序通过管道传给 shell。下载产物，验证它们，然后运行它们。以下步骤说明如何操作。

下一版本为 1.0，是 Community 和 Business/Enterprise 的首个稳定版本。目前尚未发布。功能及其当前限制另有说明。诚实与局限。

发布版本附带什么

标记的发布携带二进制档案加上证明它们所需的一切：

认证按字节引用每个产物，绝不通过可变标签。

一命令路径

请从发布标签对应的可信源代码检出中获取 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；脚本使用该密钥验证 Helm chart 和保存的镜像，无需 Rekor。信任该包之前，应将其公钥与通过另一渠道从密钥所有者收到的副本进行比对。包内的密钥本身不能证明该包的真实性。镜像必须带有使用该密钥生成的签名，才能通过验证。

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 产物。