半秒延迟：XZ Utils 后门背后的真相
Half a Second – a book about the XZ backdoor
2024 年 3 月，一名 Microsoft 工程师在家测试时，发现登录测试机慢了半秒。大多数人会忽略这种波动，但他却追根究底，最终挖出了 XZ Utils 中的隐藏后门。这款几乎每台 Linux 系统都在用的压缩工具，竟被某人花了两年时间植入恶意代码。本书《Half a Second》讲述了这场惊心动魄的攻防战：一位精疲力竭的志愿者如何被精心操控交出代码，一名工程师如何凭直觉和运气识破攻击，以及幕后黑手至今仍未浮出水面。更深层的问题在于，全球数字基础设施中，许多关键的小众组件仅靠少数无偿志愿者维护，这种结构性失衡让隐患悄然滋生。
大多数人会把这半秒的延迟当作噪音忽略，但他却选择追查下去，最终发现了一个后门：一个隐藏在 XZ Utils 中的、故意构建的入口。
HN 评论区
53- this_user
嗯，‘关于作者’这一栏大概应该直接改成指向 claude.ai 的链接吧。
- OldMatey
考虑到投入的时间和精力，以及恰好有一位勤勉的人及时发现、调查并揭露了此事，防止其进一步扩散……在我看来，这种情况很可能已经发生在其他库中，只是尚未被发现。
- skippyfish
以下是作者开发的工具，几乎可以肯定整本书都是用它生成的——“一个用于撰写长篇非虚构作品的结构化流程，打包为 Claude Code 技能”：
https://github.com/AdrianMastronardi/bookwright
关于 xz 漏洞的公开信息远不足以支撑写成一本书，所以抛开 AI 生成文本的优劣不谈，这简直是一种极其低效的学习该主题的方式。
- dhx
参见 [1]，这是 2024 年 4 月对 xz 后门进行的 Clickhouse GitHub 活动分析。
我还没见过有人写出包含以下考量的完整分析报告：
- 将 GitHub 活动（例如 GitHub 端的所有 API 操作，包括回复评论）、邮件列表活动以及其他面向公众的活动综合起来分析。
- 公开操作的复杂性，例如是否存在一堆需要 20 小时工作量才能凑齐的代码变更，结果却一次性提交？是否出现过长时间的高频活动，从而可能揭示参与人数？
- 公开操作的延迟，例如如果某个路人提出了问题，攻击者花了多久才回应，随后又花了多久解决并提交补丁？与公开操作的复杂性类似，通过估算经验丰富的开发者修复问题所需的时间与实际耗时（包括工作量和时长），可能揭示参与人数。
- 团队在国际上的分布情况，涉及不同时区，以及用于协作、审查和对外活动的核心时段。
- 公共假期、特定国家/地区的工作习惯等——例如考虑“暑假”等常见假期，或考虑异常的低/无活动日（如雪天、停电等攻击者可能经历的情况）。
GitHub 上的操作分布表明，攻击者采用了每周工作 6 天的模式，排除了 […]
- kreyenborgi
关键在于这本书是从哪里开始的，而不是它讲了什么。