composer如何验证包签名？（SLSA与供应链安全初探）

Composer install 校验包的 SHA-256 完整性（dist.shasum）和 HTTPS 传输安全，不验证开发者数字签名；关键组件需手动验证 Git tag 的 GPG 签名，并启用 Packagist 元数据 GPG 验证（≥2.2 版本）。 Composer 本身不验证开发者数字签名，它验证的是包的完整性（shasum）和元数据来源（HTTPS + 可选 GPG），不是“谁签的”，而是“是不是原包、是不是从可信源来的”。 composer install 时到底校验了什么？ 你执行 的那一刻，Composer 已经在后台做了两件事： 比对 中每个包的 和实际下载 ZIP/TAR 包的 SHA-256 值 —— 不匹配直接报错，提示 或 ； 强制走 HTTPS 连接仓库（如 ），校验 TLS 证书链，防止中间人劫持或镜像投毒。 这不是“签名验证”，是“传输+存储双重哈希校验”。它能防篡改、防下载污染，但不能证明“这个包是 Laravel 官方亲手打包并签名发布的”。 想验证“谁发布的”？得靠 Git 标签 GPG 签名 + 手动操作 Composer 对 Git 仓库（VCS 类型依赖）不自动验签，但你可以自己验证维护者是否对发布版本打了可信 GPG 标签： 先确保已导入作者公钥： ； 克隆仓库： ； 检出 tag 并验证： —— 输出含 且密钥指纹匹配才可信； 然后在 中显式引用该 tag： 或通过 VCS 仓库配置 + 锁定。 注意：如果项目没打 GPG tag，或者你没导入对应公钥， 会显示 —— 这不是 Composer 的问题，是发布方未启用或你未准备验证环境。 生产环境必须开启 Packagist 元数据 GPG 验证 Packagist 自 2021 年起对 等元数据文件做 GPG 签名，Composer ≥ 2.2 支持自动校验。不启用，攻击者可能伪造搜索结果、注入恶意包链接： Composer 2.9.6 Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。 下载 检查当前版本： （必须 ≥ 2.2）； 启用签名验证： ； 公钥可从官方获取： ； 验证生效：运行 ，若看到 且无报错，说明成功。 漏掉这步，等于信任整个包索引页 —— 而索引页本身可能被供应链攻击污染。 别被 roave/composer-gpg-plugin 带偏方向 社区插件 听起来很安全，但它只在包维护者主动为每个 release 提交 GPG 签名的前提下才有效。现实中绝大多数 Packagist 包根本没配这个流程，装了也白装，还可能因签名缺失导致安装失败。 更务实的做法是：优先用 HTTPS + shasum 校验保底，关键组件（如支付 SDK、加密库）手动核验 Git tag 签名，再配合 扫已知漏洞 —— 签名只是纵深防御的一环，不是银弹。 真正容易被忽略的是： 文件必须提交到 Git，且每次更新都要人工审查 diff；否则，哪怕所有校验都通过，一个被悄悄替换的 lock 文件就能让整套验证形同虚设。