Composer install 校验包的 SHA-256 完整性（dist.shasum）和 HTTPS 传输安全，不验证开发者数字签名；关键组件需手动验证 Git tag 的 GPG 签名，并启用 Packagist 元数据 GPG 验证（≥2.2 版本）。
Composer 本身不验证开发者数字签名，它验证的是包的完整性（shasum）和元数据来源（HTTPS + 可选 GPG），不是“谁签的”，而是“是不是原包、是不是从可信源来的”。
composer install 时到底校验了什么？
你执行 composer install 的那一刻，Composer 已经在后台做了两件事：
- 比对
composer.lock中每个包的dist.shasum和实际下载 ZIP/TAR 包的 SHA-256 值 —— 不匹配直接报错，提示Signature mismatch或package is corrupted； - 强制走 HTTPS 连接仓库（如
https://repo.packagist.org），校验 TLS 证书链，防止中间人劫持或镜像投毒。
这不是“签名验证”，是“传输+存储双重哈希校验”。它能防篡改、防下载污染，但不能证明“这个包是 Laravel 官方亲手打包并签名发布的”。
想验证“谁发布的”？得靠 Git 标签 GPG 签名 + 手动操作
Composer 对 Git 仓库（VCS 类型依赖）不自动验签，但你可以自己验证维护者是否对发布版本打了可信 GPG 标签：
- 先确保已导入作者公钥：
gpg --keyserver keyserver.ubuntu.com --recv-keys ABCDEF1234567890； - 克隆仓库：
git clone https://github.com/vendor/package.git； - 检出 tag 并验证：
git tag -v v2.3.4—— 输出含Good signature且密钥指纹匹配才可信； - 然后在
composer.json中显式引用该 tag："vendor/package": "dev-main#v2.3.4"或通过 VCS 仓库配置 +minimum-stability: stable锁定。
注意：如果项目没打 GPG tag，或者你没导入对应公钥，git tag -v 会显示 Can't check signature: No public key —— 这不是 Composer 的问题，是发布方未启用或你未准备验证环境。
生产环境必须开启 Packagist 元数据 GPG 验证
Packagist 自 2021 年起对 packages.json 等元数据文件做 GPG 签名，Composer ≥ 2.2 支持自动校验。不启用，攻击者可能伪造搜索结果、注入恶意包链接：
- 检查当前版本：
composer --version（必须 ≥ 2.2）； - 启用签名验证：
composer config --global signing-key /path/to/packagist.pub； - 公钥可从官方获取：
curl -s https://packagist.org/keys/packagist.pub | gpg --dearmor > /usr/share/keyrings/packagist.gpg； - 验证生效：运行
composer update -vvv，若看到Verifying packages.json signature...且无报错，说明成功。
漏掉这步，等于信任整个包索引页 —— 而索引页本身可能被供应链攻击污染。
别被 roave/composer-gpg-plugin 带偏方向
社区插件 roave/composer-gpg-plugin 听起来很安全，但它只在包维护者主动为每个 release 提交 GPG 签名的前提下才有效。现实中绝大多数 Packagist 包根本没配这个流程，装了也白装，还可能因签名缺失导致安装失败。
更务实的做法是：优先用 HTTPS + shasum 校验保底，关键组件（如支付 SDK、加密库）手动核验 Git tag 签名，再配合 composer audit 扫已知漏洞 —— 签名只是纵深防御的一环，不是银弹。
真正容易被忽略的是：composer.lock 文件必须提交到 Git，且每次更新都要人工审查 diff；否则，哪怕所有校验都通过，一个被悄悄替换的 lock 文件就能让整套验证形同虚设。
