Python 生态回应 eMudhra 中间证书泄露事件

本节详细介绍多个 Python 项目的当前状况。积极安全文化的一个方面是“无责事后复盘”，我们只能改进未来，而最好的方式是站出来支持你所依赖的项目和维护者。请注意，下面的所有决定都有其历史背景和合理理由：Python 的年龄与 TLS 大致相当，并且远早于“系统应具备最新且安全的 CA 证书包”这一预期的出现。

Python 生态系统中需要对该事件迅速做出响应的关键组件是“certifi”以及安全公告 GHSA-6q48-6c7w-9gw2。Certifi 是 Mozilla CA 证书包的 Python 打包版本，被包括 pip 和 requests 在内的许多流行项目使用。该包只包含根 CA，不包含中间 CA，因此需要从 CA 证书包中移除根 CA（“emSign Root TLS CA - G3”），以不信任所有受影响的中间证书。

长话短说：certifi 是一个关键依赖，它使得 Python 虚拟环境能够引导自身从 PyPI 安装软件包。pip 捆绑了其依赖项，其中包括依赖 certifi 的“Requests”。Python 捆绑了 pip，因此新的虚拟环境总是通过名为“ensurepip”的机制包含 pip。

这种安排使得 Python、pip 和 certifi 这三个组件都处于用户通过软件更新永久修复此事件的关键路径上。对于旧版本的 Python 也没有简单的解决方案，由于兼容性考虑，这些版本将永久包含旧版本的 pip。为解决这一问题，Python 添加了一个“最后手段”拒绝列表，在 TLS 握手期间拒绝被入侵的中间证书，修复版本和更多信息通过 CVE-2026-115557 跟踪，该修复已向后移植到旧版本的 Python。

我们继续通过安全公告和 CVE 提醒用户，并在 PyPI 和 discuss.python.org 上使用横幅提示，同时将密切关注“certifi”修复版本在整个生态系统中的采用情况。即时的同步响应已经结束，现在我们转向应该优先处理的事项，以便未来类似 CA 被入侵的事件可能不需要志愿维护者做出如此紧急的响应。

从事件一开始就发现，浏览器进行的 TLS 握手是安全的，但 pip、git、uv 等工具并不安全。为什么会这样？浏览器能够通过使用证书吊销列表（CRL）快速保护其证书存储，且无需软件更新。CRL 允许 CA 提供者在软件更新流程之外向验证方提供信息，例如某些证书因吊销或入侵而不应再被使用。

这些技术未来可能会集成到 Python 中，以便对未来涉及 CA 证书的事件提供更快速和稳健的响应，并允许发行版在系统范围内配置这些设施。一个值得关注的潜在项目是 upki，它已被 Ubuntu 采用，在以前不提供此类设施的平台上提供类似于浏览器的证书吊销功能。