必须强制启用HTTPS，否则所有校验机制形同虚设；Composer的签名验证、元数据完整性与包防篡改均依赖HTTPS可信通道，允许HTTP或禁用证书校验将导致中间人劫持packages.json、注入恶意dist URL、跳过signature校验，使vendor代码面临污染风险。
必须强制启用 HTTPS，否则所有校验机制都形同虚设。 Composer 的签名验证、元数据完整性、包文件防篡改，全部建立在 HTTPS 通道可信的基础上；一旦允许 HTTP 源或禁用证书校验，中间人可替换 packages.json、注入恶意 dist URL、跳过 signature 字段校验——你 install 的每一份 vendor 代码，都可能已被污染。
为什么 secure-http true 是底线，不是可选项
Composer 默认开启 secure-http，但很多老项目或 CI 脚本会显式关闭它来“绕过证书错误”。这是最危险的操作之一：
-
composer config -g secure-http false→ 允许任何 HTTP 镜像（如http://packagist.phpcomposer.com），元数据可被劫持重写 - 即使镜像地址写的是
https://，若服务端 TLS 配置有缺陷（如缺少中间证书、使用弱密码套件），secure-http: true仍会拒绝连接——这不是 bug，是保护 - PHP cURL 扩展若未编译进 CA 证书包（常见于 Docker Alpine 镜像），也会触发
SSL certificate problem报错，此时应修复 CA 信任链，而非关secure-http
如何确认 HTTPS 安全链路真正生效
光配了 https:// 不代表安全。要验证三件事是否同时成立：
- 运行
composer diagnose，输出中必须同时出现：secure-http: OK和signature verification: OK - 检查
composer config --list --global中repos.packagist.url是否为 HTTPS 地址，且域名属于可信镜像（如https://mirrors.aliyun.com/composer/） - 执行
composer show packagist.org或composer update --dry-run，观察请求日志里是否全程走 HTTPS，无 301 重定向到 HTTP
镜像源配置的致命误区：别用 repo.packagist 替换官方源
这条命令：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，看似加速，实则主动弃守签名验证防线：
- 它把官方源
https://packagist.org完全替换成镜像，而国内镜像不提供signature字段，composer install会静默 fallback 到无校验模式 - 正确做法是保留官方源语义，仅代理元数据：
composer config -g repos.packagist.type composer+composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 这样
packages.json从镜像 HTTPS 加速获取，而包文件（.zip/.tar）仍由 Composer 内部通过官方签名验证逻辑下载，校验链不断
私有仓库也必须走 HTTPS，且验证证书有效性
私有 Packagist 或 Satis 服务若部署在内网，常有人用自签名证书并配 "verify_peer": false ——这等于在防火墙里挖了个明文隧道：
- 配置中
"options": {"ssl": {"verify_peer": true}}必须显式声明，不能依赖默认值（某些旧版 Composer 默认为 false） - 自签名证书需将 CA 根证书加入系统信任库，或通过
COMPOSER_CAFILE环境变量指定路径，而非关验证 - Git 类私有源（如 GitLab）同样适用：确保
gitlab-oauth对应的域名走 HTTPS，且git clone命令本身也校验证书
HTTPS 不是开关，是一整条链：客户端证书校验 + 服务端 TLS 配置合规 + 中间镜像不绕过签名 + 私有源不降级。漏掉任一环，你加固的只是表层流量，底下的依赖树早已裸奔。尤其是 repos.packagist 的配置方式和 secure-http 的状态，这两个点最容易被脚本自动修改、CI 流水线忽略，却直接决定整个供应链的信任起点是否可靠。
