composer diagnose 报 SSL certificate problem 是因它真实发起 HTTPS 请求校验 packagist.org 的 TLS 握手、证书有效性及系统信任状态，而非仅测试连通性；常见于本地缺失企业 CA 或中间人代理证书，正确做法是配置 cafile 指向可信证书而非禁用 TLS。
composer diagnose 为什么报 SSL certificate problem
它不是网络不通，而是 Composer 真的发了 HTTPS 请求去连 packagist.org，校验 TLS 握手、证书链和系统信任状态。常见错误如 curl: (60) SSL certificate problem: unable to get local issuer certificate，说明本地没认你的企业 CA 或中间人代理证书。
别急着关 TLS——禁用 secure-http 或设 COMPOSER_DISABLE_TLS=1 会让所有包元数据裸奔，audit、signature 验证全失效。
- 先确认问题范围：
composer diagnose默认只测官方源，私有 Artifactory/Nexus 不在默认检查列表里 - 手动验证私有源：
curl -Iv https://your-artifactory.example.com/artifactory/api/composer/packagist.org/packages.json，看是否卡在 TLS 握手或返回SSL_ERROR_SYSCALL - 正确修复：把企业根证书加进系统信任链，或全局指定：
composer config --global cafile /path/to/company-ca.crt - 若用 GitHub OAuth 却报
Could not fetch，先清空 token：composer config --global github-oauth.github.com ""，再跑diagnose——如果这时通过了，说明是 OAuth 跳转环节的 SNI/OCSP 异常，不是证书本身问题
如何配置可信镜像源而不牺牲签名验证
只改 repo.packagist 为阿里云镜像（如 https://mirrors.aliyun.com/composer/）看似安全，实则绕过了 Packagist 官方签名机制——因为镜像不提供 signature 字段，composer install 会静默降级到无校验模式。
真正安全的做法是保留官方源语义，仅代理元数据请求，同时强制启用签名验证：
- 启用全局签名检查：
composer config -g security.signature-verification true（Composer 2.5+ 才支持） - 设置可信 HTTPS 镜像（仅用于
packages.json等元数据）：composer config -g repos.packagist.type composer，再执行composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 确保未禁用 HTTPS：
composer config -g secure-http true（默认开启，但项目级配置可能覆盖） - 验证是否生效：
composer diagnose输出中必须同时出现secure-http: OK和signature verification: OK
allow-plugins 怎么配才不算放行恶意代码
allow-plugins 是 Composer 2.2+ 的插件白名单机制，默认阻止一切插件运行。设成 true 全局开启等于直接卸掉门锁。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置最可控，且便于审计：
- 在
composer.json的config段明确列出可信插件："allow-plugins": { "symfony/flex": true, "laravel/pint": true, "phpstan/extension-installer": true } - 避免使用通配符或模糊匹配，比如
"*/*"或"vendor/*"—— 这些在新版 Composer 中已被拒绝 - 私有插件必须带完整命名空间，且其包需经内部安全扫描后才可加入白名单
- CI 流水线中应加检查：
composer validate --no-check-publish确保allow-plugins不含true字面值
vendor 目录权限为什么不能靠 Composer 自己管
Composer 从不修改文件权限，vendor/ 下的 PHP 文件、autoload 映射、bin 脚本的权限完全取决于你执行命令时的 umask 和宿主环境。用 root 跑 install 后得到一堆 664/775 文件，等于给攻击者留了后门入口。
必须在系统层干预：
- 部署前设
umask 0022（文件 644，目录 755），Dockerfile 中写死：RUN umask 0022 && composer install --no-dev - 安装后立即加固：
find vendor/ -type f -exec chmod 644 {} \;+find vendor/ -type d -exec chmod 755 {} \; - 特别处理
vendor/bin/：chmod 755 vendor/bin/*（可执行但不可写） - Web 服务器不能直接读
vendor/——Nginx 必须加location ^~ /vendor/ { return 403; }，DocumentRoot 应严格指向public/
最容易被跳过的其实是 post-install-cmd 脚本，它们可能在安装后悄悄创建可写 symlink 或目录，这类操作不会被 umask 控制，只能靠安装后 chmod 扫描兜底。
