Deno 2.9.8 里最该看的一条：它开始不信任被攻破的 eMudhra 根证书

Deno 2.9.8 是 10 月 21 日的补丁版，13 条修复。补丁版通常没什么可写的，但这个版本有两条值得单独拎出来：一条是不再信任被攻破的 eMudhra 证书颁发机构，另一条是**deno compile 开始检查动态 import 的读权限**。

先把 13 条按性质分类

类别	条目
安全	不再信任 eMudhra CA；rand 升到修补版
权限 / 沙箱	deno compile 检查动态导入本地文件的读权限；op context 保活到 isolate 释放
Node 兼容	X.509v1 证书处理与 OpenSSL 对齐；mock.reset() 恢复 mock.method()；assert 支持消息函数与格式化参数
NAPI	napi_create_dataview 溢出边界检查；异常挂起时忽略回调返回值
工具链	zsh 补全 deno run 的脚本路径；coverage 跳过 V8 code cache；npm 包链接名校验
运行时	hyper / hyper-util 升级，连接池空时取消 idle 定时器

eMudhra 这条：证书信任是被攻破后最慢的一环

eMudhra 是印度的 CA。它被攻破之后，各家客户端要做的事只有一件：把它从信任库里删掉。难的不是删，是删得完整 ——

• 操作系统有自己的根证书库；
• 运行时（Node、Deno、Go、Python 的 certifi）常常自带一份；
• 语言包管理器托管的解释器（比如 uv 管理的 CPython）又各自带一份；
• 每一份的更新节奏都不一样。

所以你会看到同一件事在几天内被不同项目各修一遍：Deno 2.9.8 删了它，uv 0.13.4/0.13.5 删了它并顺手把托管的 CPython 升到带 certifi 2026.10.19 的版本。这不是重复劳动，是每个信任库都得自己动手。

对使用者的动作很具体：如果你的服务要和某个仍在使用 eMudhra 签发证书的站点通信，升级 Deno 之后会开始握手失败。这是预期行为，处理方式是让对方换证书，而不是给自己加信任例外。

compile 的读权限：一个「编译产物该不该继承权限」的问题

deno compile 把脚本打成单文件可执行程序。它之前的问题很微妙：动态导入本地文件时，没有检查读权限。

// 运行时动态拼出来的路径，compile 之后同样会去读
const mod = await import(new URL('./plugins/' + name + '.ts', import.meta.url).href);

静态 import 的路径在打包时是已知的，动态 import 不是。如果权限模型只覆盖前者，那 --allow-read 的边界就形同虚设：随便拼一个路径就能读到任意文件。

这类问题的普遍性值得记住 —— 凡是「打包期已知」与「运行期才定」的分界，都是权限检查容易漏的地方。同样的形状在 Node 的 realpathSync 那条修复里出现过：静态检查了，但解析符号链接之后没再查一次。

Node 兼容层的三条

Deno 的 ext/node 是把 Node 内置模块按 Deno 的方式重实现一遍，所以它的 bug 报告里永远有一类：「Node 里这样是对的，Deno 里不是」。

• X.509v1 证书处理与 OpenSSL 对齐：v1 证书没有扩展字段，历史上各实现的处理差异很大。TLS 握手细节不一致，表现出来就是「某些站点在 Deno 里连不上」。
• mock.reset() 恢复 mock.method() 的实现：测试里 reset 的语义是「清掉调用记录」，不是「把 mock 拆了」。不恢复实现的话，同一个 spy 在 reset 之后会变成空函数，后续断言全错。
• assert 支持消息函数与格式化参数：这条纯属对齐 Node 的行为，但影响面不小 —— 大量测试库里写的是 assert.equal(a, b, () => 'context')。

我的判断

Deno 现在的定位很清楚：它是「Node 兼容 + 默认安全」的那个运行时，所以它的补丁版内容天然一半在安全、一半在兼容。2.9.8 没有新特性，但 eMudhra 那条如果你在跑 TLS 客户端，值得今天就升。

顺带一个观察：这一周里 eMudhra 同时出现在 Deno、uv、CPython 的更新说明里 —— 一次 CA 事故，会让生态里每一份自带根证书库的软件都发一次版。这提醒我，任何「自带信任库」的设计都要准备好高频发版的能力，否则一次事故会拖几个月。