Apple 的 git 仍然信任已被攻破的 eMudhra 证书

原文 ↗ Hacker News 讨论 ↗

Apple 对已被攻破的 eMudhra TLS 证书的处理遭到批评，因为 macOS 仍在 `/etc/ssl/cert.pem` 中附带一个信任这些证书的 CA bundle，导致 git、curl、Python 和 OpenSSL 等命令行工具仍然暴露在风险之下，尽管 Safari 和其他图形界面应用已经通过 Apple 自己的信任框架迅速获得保护。评论者批评 macOS 上存在两个独立的系统信任存储、Apple 迟缓且依赖手动的修复指导，以及操作系统更新会悄悄撤销用户自行应用的修复。此事件还凸显了操作系统、容器和语言之间证书管理碎片化的更深层问题，并重新引发了对更好的集中式吊销机制和信任存储设计的呼声。

真正出问题的地方

  • 问题比 Git 更广泛：许多 macOS 命令行工具（git、curl、python3、ruby、perl、openssl 等）都使用 /etc/ssl/cert.pem，而其中仍包含允许通过已被攻破的 eMudhra 中间证书建立链路的根证书。
  • 使用 Apple Security/Keychain 栈的图形界面应用（Safari、常见 Mac 应用）已经很快更新，因此不会信任这条坏的链路。
  • macOS 实际上有两个独立的信任存储：Apple API 使用的 Keychain，以及 Unix 风格工具使用的 /etc/ssl/cert.pem，这造成了分裂和混乱。

Apple 的回应与不足

  • Apple 发布了官方支持文章，说明用户如何手动编辑 /etc/ssl/cert.pem 来移除某些根证书（以及可选的相关 Sectigo 根证书）。
  • 多位评论者认为这不可接受：用户必须运行 sudo shell 命令，系统更新会把改动覆盖掉（例如 macOS 27.2 重新恢复了这些坏证书），而且至今没有快速的自动修复推出。
  • 有人猜测 Apple 把命令行工具当作二等公民，并且对其“后台/快速”安全更新渠道在 Unix 组件上的使用速度很慢，甚至不愿意使用。

临时解决方案与生态反应

  • 建议的缓解措施包括：
    • 按 Apple 的说明手动编辑 /etc/ssl/cert.pem。
    • 使用 Homebrew 或 MacPorts 版本的 curl 和 OpenSSL，它们自带各自的 CA bundle；Homebrew 正在更新 git，使其不再使用系统 bundle。
    • Git 远程仓库尽量改用 SSH，而不是 HTTPS（不过 SSH 也有自身的信任问题）。
  • 社区分享了脚本和一行命令来自动执行 Apple 的说明；也有人提醒不要把随手复制的 sudo 命令正常化。

安全影响与严重性争论

  • 许多人认为这构成严重的中间人攻击风险，尤其是在公共 Wi‑Fi 或被入侵的路由器上；像 mitmproxy 这样的工具已经支持滥用这条坏链路。
  • 也有人认为影响被夸大，表示攻击者必须控制本地网络，而且既然很多设备已经打过补丁，大规模利用现在应该会被察觉。
  • 多条评论指出了更广泛的 PKI 问题：证书颁发机构存储分裂（按应用、容器、语言分别管理）、吊销机制薄弱或几乎不用，以及当只打包根证书时，如何干净地取消信任中间证书的困难。

元讨论：Apple、Linux 与信任模型

  • 有人把这件事当作支持转向 Linux 的理由；也有人反驳说所有平台都曾有严重的安全失误。
  • 还有批评认为，Apple 一直把自己包装成“安全优先”，却没能为自家的 Unix 工具及时推出集中式修复。