可重现构建验证

核心问题：供应链中的可重现盲区

在包生态系统里，攻击者可能篡改上游构建产物，而常规部署流程只能验证包来自官方源，无法判断同一源代码经不同环境重建后是否得到字节级一致的工件。OSS Rebuild 提供的可重现重建能力本应消除这一盲区，但如果下游团队从不对比上游证明与本地重建结果，这些工件仍可能被篡改或引入隐藏依赖。

工作机制与核心能力

oss-rebuild CLI 是技能的核心接口，主要完成以下工作：

• 查询重建证明与元数据：从 Google OSS Rebuild 数据库拉取目标包的证明文件和重建元数据，涵盖哈希、签名及构建环境描述。
• 比对上游与本地工件：通过 get 命令获取重建配方，用容器化或远程执行方式重建包，然后校验生成工件的哈希是否与上游证明匹配，确保同一输入产生相同输出。
• 本地重建验证：对支持的包生态（如 PyPI），直接生成 Dockerfile 并本地重建，对比 absl-py 2.0.0 这类包的构建结果，让开发者能在 CI/CD 或预部署阶段发现可重现性问题。

适用边界与注意点

• 环境依赖：需在目标环境安装 Go 工具链和 oss-rebuild CLI，部分签名验证可能需 GCP ADC 凭证。
• 支持的包生态有限：当前主要支持 PyPI（Python）等生态，其他生态需参考上游文档确认支持情况。
• 重建结果依赖上游数据：若上游证明或元数据被篡改，验证结果将失效，需依赖 OSS Rebuild 的分发安全机制。

该技能聚焦于构建阶段验证，无法替代运行时依赖扫描或签名审计，适合在 CI 流水线或本地开发环境中作为可重现性检查环节。