uv 0.13.5：换掉被攻破的根证书，顺手把托管的 CPython 升到三个安全补丁版

uv 0.13.5 在 10 月 21 日发布，两个版本连起来看才完整：

• 0.13.4：从 uv 自己的证书库里删掉被攻破的 eMudhra / emSign 根；
• 0.13.5：把托管的 CPython 构建全部换到 python-build-standalone 20261021，包含 3.15.1、3.14.9、3.13.17 三个安全补丁版，并带上 pip 26.2.2 与 certifi 2026.10.19。

为什么一个包管理器要自己管根证书

这是很多人第一次意识到的事：uv 下载东西时，用的不是系统的证书库。

理由很实际 —— 如果依赖系统证书库，那在 macOS 上要处理钥匙串、在 Windows 上要处理 CryptoAPI、在 Linux 上要看发行版怎么打包 CA 包，而且系统证书过期或缺失会让安装直接失败。所以 Go、Rust、Node 的一部分工具链、以及 uv，都自带一份根证书。

自带的代价是：CA 事故发生时，每个自带证书库的软件都要单独发一次版。这一周里 eMudhra 同时出现在 Deno 2.9.8、uv 0.13.4、CPython 的更新说明里 —— 就是这个原因。

托管的 Python 也要换

第二层更隐蔽。uv 可以下载并管理 CPython 解释器（uv python install 3.13），这些解释器是预编译好的 python-build-standalone 构建。它们里面也有自己的东西：

组件	为什么和证书有关
certifi	Python 生态的根证书包，独立于系统
pip	装包时要走 HTTPS，用的是 certifi
ensurepip	创建 venv 时默认装的 pip 来自这里

所以「系统证书库删了 eMudhra」不等于「Python 里的 certifi 删了」—— 后者要等 certifi 发新版本（2026.10.19），再等 uv 把它打进新的 CPython 构建。

关键一步：uv python upgrade

发布说明里有一句必须看到：

After upgrading uv, run uv python upgrade to install the updated builds. Virtual environments pinned to an older Python patch version do not switch to the updated interpreter.

也就是说：

# 1) 升级 uv 自己
uv self update

# 2) 让托管的解释器也升级
uv python upgrade

# 3) 检查结果
uv python list --only-installed

而已经固定在旧补丁版的 venv 不会自动换。这是有意设计：venv 记录的是具体解释器路径，换了解释器等于换了运行时，可能让依赖里的二进制扩展失效。

所以真实场景是这样：你升级了 uv、跑了 uv python upgrade，新建的 venv 用的是新解释器，但老项目的 venv 还是旧解释器，证书还是旧的。要彻底干净，得重建 venv。

# 重建（会重装依赖，适合 CI 与容器）
rm -rf .venv
uv venv && uv sync

我的判断

这条更新本身没有漏洞可修（eMudhra 的移除在 0.13.4 已完成），0.13.5 是把修复铺到所有托管的运行时里。它说明 uv 的发布模型是「工具与运行时分开管，但版本一起发」。

实际操作建议：

1. CI 里固定 uv 版本，升到 0.13.5 之后重建缓存与 venv，别指望原地生效；
2. 生产镜像里显式跑一次 uv python upgrade，否则镜像里躺着的还是旧解释器；
3. 如果你有「证书链固定」的需求（比如对接只信任特定根的内部服务），这次升级会改变信任集 —— 先测再发。

顺带记一条

这类「运行时分发」的项目越来越多（uv 管 CPython、Bun 管 Node 兼容层、Deno 管自己的运行时）。它们带来的好处是版本可控，代价是信任库、CA、TLS 这些基础设施问题变成每个工具各自的事。

作为一个经常要解释「为什么升级一个包管理器能影响 HTTPS」的人，我觉得这句话值得写下来：自带证书库的工具，必须能高频发版，否则一次 CA 事故会拖几个月。