2011 年 8 月 28 日，管理员发现 kernel.org 遭到入侵。自那一刻起，分发 Linux 内核的那些机器便失去了可信基础；既有 Git 历史是否遭过改动，仍然可以检验。项目经过广泛调查后报告，仓库没有遭到篡改，但基础设施仍从零重建，凭据全部更换，归档签名密钥退役，多数服务离线数周。[1][2][7]

这组同时成立的事实，是整起事件最值得辨析之处。“源代码完好无损”与“托管源代码的主机已被攻击者取得 root 权限”都是真的。Git 让一种完整性可以由外部独立核验；服务器进程、操作 ref 的人员、为 tarball 签名的密钥，以及卷入同一凭据链的开发者端点，都不在它的证明范围内。

因此，这份事后报告呈现了 可信来源 的三重含义：

• 对象完整性： 这些特定的 blob、tree 和 commit，正是标识符早已为我们所知的那段历史。
• 发布授权： 某位公认的维护者有意发布这段特定历史或归档。
• 运行时完整性： 负责交付内容的机器没有窃取凭据、篡改响应或滥用相邻服务。

入侵之后，第一项主张仍有证据可查，第二项需要重建；一旦确认主机落入敌手，第三项便已经失效。

图片背景：LWN 的合影摄于 2011 年 10 月布拉格 Kernel Summit。10 月 24 日，kernel.org 报告列在当天讨论的第一项。拥挤的画面之所以重要，是因为恢复工作涵盖的范围超出了磁盘重装：维护者还要在一个分布式社群中重新确立身份、密钥、托管界线与协作约定。[1][9]

分发节点悄然变成了控制平面

Kernel.org 起初用于分发内核发行版。到了 2011 年，它还托管 Git 仓库、Bugzilla、Patchwork、wiki、kerneloops.org、电子邮件服务和一套定制的 gitweb 层。这一转变逐步发生：每项服务各有用途，叠加起来却让一个发布站点变成了身份与协作高度集中的枢纽。[1]

从现有证据看，攻击者没有把 Linux 项目选作一次源代码行动的特定目标。Kernel Summit 报告描述了一张覆盖范围更广的凭据窃取网络，它此前已经控制许多机器。攻击者植入木马化的 ssh 和 sshd 二进制文件，监视终端会话，记录用户名和密码；调查线索还显示，他们利用转发的 SSH agent 进入更多系统。攻击者一直低调活动，调查人员没有发现他们改动 kernel.org 数据的证据。[1]

最后这句话是一项取证结论，架构层面的风险并未因此消失。任何在受影响主机上输入的密码、存放于其中的私钥，以及经由失陷链路暴露的凭据，都必须按已经泄露处理。即使仓库对比结果干净，也无法让已被截获的密码重新成为秘密；同样无法证明正在运行的 SSH daemon 就是软件包数据库所声称的那个二进制文件。

服务中断让长期累积的耦合显露出来。Kernel.org 下线后，内核开发放慢，原定的 Linux 3.1 发布继续搁置。10 月 3 日，一个最小化站点恢复上线，只提供 mainline、stable 和 linux-next Git 树；其他维护者需要先检查自己的系统、生成新密钥并重新取得访问权限。[2] Git 的分布式特性让开发工作得以延续，但共享协调节点仍然重要，它的缺席依旧改变了发布节奏。

Git 给响应人员留下一项独立于服务器的不变量

Git 以对象图存储内容。blob（数据对象）的地址由其内容与 header 的哈希决定；tree（树对象）指向带名称的 blob 和子 tree；commit（提交对象）指向顶层 tree，以及一个或多个父 commit。修改旧的源文件后，它的 blob 标识符会改变，包含它的 tree 随之改变，引用该 tree 的 commit 也会改变，所有以这个已变 commit 为祖先的后续 commit 同样会改变。[3][5]

有了这套安排，服务器外部早已保存的信息便可用于检验无声改写。内核开发者在各自独立的机器上拥有完整 clone，也掌握既有 commit 标识符，并且频繁 pull。Linux Foundation 当时的说明强调了防线的两个部分：内容寻址会让改写后的历史换上新标识符，大量彼此独立的仓库则留下失陷服务器无法控制的比对点。[3]

在本地执行这项检查，可以使用 git fsck --full。它会检查松散对象和 pack 对象的哈希、对象有效性、可达性及图的连通性。hash mismatch 代表严重的完整性故障，缺失对象则会暴露断裂的对象图。[6] 在恢复期间，这些特性可用来回答：这个仓库是否完整保存了那段已知历史？

它们回答不了另一个问题：这个分支顶端值得信任吗？ 服务器管理员可以把某个 ref 指向一个新建、内部完全有效的恶意 commit。Git 会忠实核验那段历史中的每个对象，却无法判断这次 ref 移动究竟由 Linus Torvalds 授权，还是由入侵者发起。恶意 Git 服务还可以攻击有漏洞的客户端，或者向不同访客给出不同的 ref 通告。内容寻址限制了伪造已知历史的空间，却无法把不可信的运行时变成无害的文件服务器。

正因存在这条界线，“Git 未遭入侵”只能作狭义理解。调查没有发现数据篡改，分布式对象图也留下了支持这项结论的有力证据。[1][3] 这项结论的范围不包括主机上每项服务的安全性、每份可下载归档的认证状态，以及访问这些机器所用凭据是否仍然可信。

归档签名指向了错误的主体

2011 年 9 月以前，kernel.org 使用一把 Linux Kernel Archives 密钥为发行包自动签名。现行签名文档记录了恢复阶段一个令人不安的判断：系统遭入侵后，该密钥于 2011 年 12 月 11 日退役并撤销，今后不得再使用。Kernel.org 表示，这把私钥几乎肯定落入了恶意人员手中。[7]

密钥原先所处的部署位置，使它表达的声明比许多用户以为的更弱。自动签名只能证明一份归档经过了 kernel.org 的签名流程。分发主机与签名凭据一同失陷时，签名无法独立证明某位维护者有意把这些字节发布为发行版。它只是以密码学形式复述了主机自己的声明。

Kernel.org 后来交叉核验旧发行版，使用一把专为这项工作创建的一次性密钥重新签名，随后销毁私钥部分，使其无法再为今后的任何制品背书。[7] 现行工作流把两项声明分开。一套专用的离线系统为校验和签名，帮助用户比对镜像内容与中央存储；文档同时明确指出，这些校验和无法取代开发者签名。维护者签名给出了授权声明，而镜像一致性无法提供这项证明。[7]

这次恢复触及的层次，比更换算法或生成更长密钥更深：签名主体发生了变化。“内容来自 kernel.org”与“某位内核维护者发布了它”成为两项分开的声明，传输和授权各自留下证据。

重建收缩了随环境附带的权限

9 月 23 日，H. Peter Anvin 在发给内核邮件列表的消息中介绍了替代基础设施。开发者此后不能再通过 shell 访问 Git 仓库。Gitolite 使用新的 SSH 凭据居中管理 push；其余服务会依据资源情况逐步恢复，前提是能够安全运维。[4]

Kernel Summit 报告又补充了组织层面的界线。各项服务将更彻底地分开，运维工作全部转入 Linux Foundation，并增加人员投入；root 权限只保留给全职管理员。已经在其他地方稳定运行的邮件列表继续留在原处，不会并入重建后的主机。[1]

发行包上传方式也随之改变。kup 工具只在对照预先批准的维护者名单完成密码学验证后，才接收提交给 kernel.org 的软件。文档规定的流程要求为未压缩的 .tar 提供签名，验证通过后再处理用于发布的压缩格式。自动发布路径始于带签名的 Git tag，并据此确定源代码树，以及获准从该树发布的维护者。[8]

每项控制都有自己的失效方式。Gitolite 会出现漏洞，维护者密钥会遭窃，全职人员也会犯错。改进来自这些控制的组合：Web 应用访问仓库时不再持有通用 shell 权限；分发主机不能靠签署到达它的任意内容自行创造发布授权；各项协作服务也分散到不同机器上。一处故障因此少了许多自动蔓延至下一个信任域的通道。

恢复需要四项证明，不能只靠一个干净的 clone

这起事件为自行运行 forge 或发行主机的项目留下一套紧凑的恢复模型。

状态证明用于确定预期的仓库对象图。把完整对象标识符和 ref 与已知的独立 clone、签名 tag、发行清单或其他外部记录逐一比对。若备份生成于攻击者控制系统期间，其中也会保存攻击者留下的状态，因此单独一份备份并不足够。

授权证明用于确认谁有意推进这张对象图。用签名密钥核验 tag 或清单，而该密钥的指纹应从失陷服务以外取得。只要密钥曾存放于这台主机，或经由它传输，就要轮换密钥，并通过独立渠道发布撤销信息。

运行时证明用于建立可信的执行基础。从已知介质重新安装或更换受影响的主机，有意识地重建配置，并签发新的服务 secret。即使 git fsck 顺利通过，也说明不了木马化 SSH 二进制文件、恶意 web hook 或被盗 CI token 的情况。

身份证明用于封闭整条凭据谱系。需要盘点暴露窗口内输入过的密码、存放过的密钥、转发过的 agent、可被读取的 token，以及当时处于活动状态的管理员会话。先撤销，再通过不依赖失陷身份的渠道重新签发。2011 年重建时采用新 SSH 凭据并收紧 shell 访问，遵循的正是这条界线。[1][4]

对于只有两名维护者的库，方案可以保持轻量：在 forge 外设置只读镜像，用硬件保护或离线密钥为发行 tag 签名，为 CI 与发布分别配置凭据，并在恢复记录中保存已知完好的 ref 和密钥指纹。维护者必须能够实际操作这些控制；一套从未演练的复杂系统，还不如一套随时能够恢复的小型系统可靠。

对于大型基金会或发行版，要求会更高。审计日志要保存在生成日志的服务之外；发行签名应与通用 Web 主机隔离；SSH agent 转发需要严格限制；动态服务应拥有各自独立的身份与故障域。恢复便利功能层之前，先演练只启用必要仓库通路的回归过程。Kernel.org 在 10 月有限恢复服务，是一个有用的范例：恢复顺序应由授权关系决定，首页功能是否齐全排在其后。[2][4]

反证测试很直接：如果攻陷一名管理员的工作站或一台公共主机，仍足以让攻击者改动 ref、发布受信任的发行版、抹去审计轨迹并窃取全部恢复凭据，那么这套架构只是给单一信任点换了一个名字。

留存下来的是证据，机器已经失信

2011 年入侵事件经常被视为 Git 篡改留痕能力的一个范例，它也确实如此。然而，Git 在这方面的成功并没有让整起事件变得无足轻重。主机被重建，归档密钥被撤销，凭据被更换，服务被拆分，发布授权重新回到各位维护者手中。[1][4][7][8]

这起事件没有给出“分布式版本控制可让托管安全变得可有可无”的结论。它留下的长久教训，是有韧性的项目会在任何一台主机之外保存充足证据，以便在该主机失信时准确判断哪些部分仍然完好。

因此，可信来源需要的远多于一个绿色勾号。它由一条彼此独立的声明链组成：这些是预期的字节；这位维护者授权了它们；这套交付系统未曾暗中替换为其他内容。Kernel.org 能够证明第一项，同时重建后两项。这种分离让一台已遭 root 权限攻陷的服务器所引发的事件，从无法判断的源代码灾难，收束成一场范围有界、代价依旧高昂的恢复工程。

来源

1. Jonathan Corbet，LWN.net，《KS2011：Kernel.org 报告》，2011 年 10 月 24 日——关于凭据窃取行动、调查结果、凭据暴露、服务扩张与重建计划的独立同期记录。
2. Jonathan Corbet，LWN.net，《Kernel.org 的恢复之路》，2011 年 10 月 4 日——关于中断对开发的影响、10 月最小化恢复以及维护者重新取得凭据流程的独立记录。
3. Linux Foundation，《Kernel.org 遭破解》，2011 年 8 月 31 日——关于 Git 对象历史与独立 clone 如何留下篡改证据的同期技术说明。
4. H. Peter Anvin，“kernel.org status”，Linux Kernel Mailing List，2011 年 9 月 23 日——涵盖从零重建、Gitolite、取消仓库 shell 访问和启用新 SSH 凭据的一手恢复通知。
5. Scott Chacon 与 Ben Straub，《Pro Git》“Git 内部原理：Git 对象”——关于内容寻址的 blob、tree、commit 及父链接的项目一手文档。
6. Git Project，“git-fsck”文档——关于对象哈希、有效性、连通性与可达性检查的一手资料，其中包括 hash mismatch 这一故障界线。
7. Kernel.org，“Linux 内核发行版 PGP 签名”——现行开发者签名与校验和签名的分工，以及 2011 年 9 月以前归档密钥的撤销和替换历史。
8. Kernel.org Documentation，“使用 kernel.org 上传工具（kup）”——现行密码学上传验证、tar 签名界线和签名 tag 自动发布工作流。
9. LWN.net，“2011 Kernel Summit 第二天合影”，2011 年 10 月 26 日——本文图片所用的档案照片。