十天后，macOS 上的 Git 仍信任被入侵的 eMudhra 证书

一个获得 306 分、127 条讨论的 Hacker News 帖子把一个略显尴尬的事实摆上了台面：当一张证书颁发机构（CA）的信任根基被动摇时，依赖它的软件栈并不会自动跟着更新。作者以「Ten days later」为题，记录了自己在 macOS 上使用 Git 时，依然看到系统信任 eMudhra 证书的现象。

事件背景：eMudhra 证书为何值得警惕

根据原帖指向的页面，问题的核心在于 eMudhra 颁发的证书被指存在被入侵（compromised）的情况。证书信任是整条 HTTPS 与代码签名链条的起点——浏览器、操作系统、包管理器、以及 Git 这样的版本控制工具，都会在底层调用系统的证书信任库。一旦某张根证书或中间证书不再可信，理论上所有使用该信任库的客户端都应当拒绝由它签发的证书。

现实中的难点在于，「不再可信」这个判断需要在每一层软件栈里落地。操作系统的信任存储更新是一回事，应用层是否真的使用更新后的信任存储、是否内置了自己的证书包，又是另一回事。原帖的观察正是落在这个缝隙里。

证书信任链与根证书：在 TLS 体系中，服务器证书通常由中间 CA 签发，中间 CA 又由根 CA 签发，形成一条可验证的信任链。操作系统和浏览器内置的「信任存储」（trust store）保存着受信任的根证书列表。当某个根证书被标记为不可信或被移除时，理论上所有由它派生的证书都应被拒绝。然而，信任存储的更新机制在不同平台上差异很大：macOS 通过系统更新推送信任变更，但应用是否读取这一存储、是否缓存了旧列表，决定了变更能否真正生效。eMudhra 事件之所以值得警惕，正是因为根证书一旦被入侵，攻击者可以伪造任意域名的证书，而信任链的撤销需要每一层软件栈同步响应，任何滞后都会形成攻击窗口。

Git 在 macOS 上的证书路径问题

Git 在 macOS 上处理 HTTPS 请求时，依赖的是底层 TLS 库（通常是系统提供的 Secure Transport 或通过 curl 链接的库）。当 Git 被配置为使用系统证书库时，它本应继承 macOS 的信任决策。但实际部署中，Git 可能通过不同的构建方式（系统自带版本、Homebrew 安装版本、官方安装包）链接到不同的 TLS 后端，导致证书信任行为不一致。

这解释了为什么会出现「系统已经处理了，但 Git 还在信任」的观感。帖子标题里的「still trusts」并不是说 Git 有独立的安全判断，而是说它的信任链路没有跟上预期的更新节奏。对于每天用 git clone、git fetch 拉取代码的开发者来说，这意味着与恶意或被入侵证书相关的风险窗口被拉长了。

TLS 后端与证书包的区别：Git 本身并不实现 TLS，而是委托给底层库。在 macOS 上，常见的后端包括 Apple 的 Secure Transport（系统自带 Git 使用）、OpenSSL（Homebrew 或官方安装包可能链接）以及 LibreSSL。不同后端读取证书的来源不同：Secure Transport 直接查询系统钥匙串，而 OpenSSL 通常读取一个 PEM 格式的 CA 包文件（如 /etc/ssl/cert.pem 或 Git 自带的 ca-bundle.crt）。如果 Git 链接的是 OpenSSL 且其 CA 包未随系统更新而刷新，就会出现「系统已撤销、Git 仍信任」的现象。开发者可以通过 git config --show-origin --get http.sslBackend 或 git version --build-options 查看链接的 TLS 库，从而判断信任来源。

社区讨论的焦点

127 条评论里，讨论集中在几个方向。其一是责任归属：证书信任的撤销应该由 CA、操作系统厂商还是应用开发者来推动？其二是可操作性：开发者能否通过手动配置 http.sslCAInfo 指向自定义证书包来规避问题。其三是更宏观的疑问——如果一张证书在十天后仍被广泛信任，那么证书生命周期管理的实际执行力度究竟如何。

这些讨论没有给出统一答案，但共同指向一个事实：信任撤销是一个跨越多层软件栈的协调问题，任何一层的滞后都会让「已撤销」停留在纸面上。

http.sslCAInfo 与自定义证书包：Git 允许通过 http.sslCAInfo 配置项指定一个自定义的 CA 证书包文件（PEM 格式），覆盖默认的信任来源。这一机制在社区讨论中被反复提及，因为它提供了一种不依赖系统更新的规避手段：开发者可以手动维护一个只包含受信任根证书的包，并在其中排除已被撤销的 CA。但这种方式也有代价——需要自行跟踪证书撤销列表（CRL）或 OCSP 状态，且配置只对当前仓库或全局 Git 生效，不影响其他工具。对于供应链安全敏感的团队，这是一种可行的纵深防御措施，但并非根治方案，因为信任管理的责任最终仍落在 CA 和平台厂商身上。

对开发者的实际影响与应对

对于在 macOS 上使用 Git 的开发者，比较务实的做法是确认自己使用的 Git 版本链接的是哪个 TLS 后端，并检查系统证书库是否已经包含最新的撤销信息。如果所在团队对供应链安全敏感，可以考虑显式指定受信任的 CA 包，而不是完全依赖默认行为。

更值得记住的是这件事暴露出的模式：证书信任的更新不是一次性的系统事件，而是一条需要各层软件协同的链路。Git 只是这条链路上的一个观察点，类似的情况也可能出现在其他依赖系统信任库的工具上。原帖的价值不在于提供解决方案，而在于用一个具体案例提醒我们，安全更新的「最后一公里」往往比想象中更长。

（本文基于 Hacker News 讨论及原帖链接内容整理，社区观点不代表确定结论。）