[Industry News] 330个“假补丁”差点混入主线?Linus Torvalds 又暴怒开喷
Tofloor
poster avatar
荔枝使
deepin
2025-06-04 17:02
Author

众所周知,Linux 内核的开发是一项庞大而复杂的工程,涉及数千名开发者的协作。在这样的高强度合作中,难免会出现一些紧张局面,甚至引发个别“火药味十足”的交流。

在上周末 Linux 6.16 合并窗口期间,原本平静的开发进程,突然被 Linus Torvalds 的一句怒吼打破:“WTF, Kees?”
是的,你没看错,Linux 内核邮件列表再起风波——而这一次的焦点,是一位老牌内核贡献者 Kees Cook,以及他提交的几百个“看起来非常不对劲”的补丁。

Linux 6.16 合并窗口突现“异常提交”,是恶意提交?

如开头所说,事情发生在 Linux 6.16 的合并窗口阶段。

上周末,Linus Torvalds 在例行检查来自各子系统维护者的提交时,突然注意到了一些非常奇怪的 Git 操作:一位长期活跃的内核开发者 Kees Cook 的代码树中,出现了高达 330 个 Pull Request。这些提交并非简单的代码更新,而是篡改了作者信息、伪造了合并历史的“假补丁”。

据悉,许多提交都声称是 Linus 发出的,也显示是 Linus 提交的。可 Linus 本人对此毫不知情:“根本就不是事实,这都是你凭空捏造出来的一堆垃圾!”

Linus 认为这种行为“具有明显恶意”,他指出其中存在伪造的合并提交,其 SHA-1 签名与原始提交不符。例如,Linus 的某个真实补丁的 SHA1 是 9d230d500b0e,而 Kees 提交中的“假版本”则使用了 f8b59a0f90a2。

愤怒之下,Linus 当即在邮件列表上直言不讳地质问道:

“你这是在恶意修改整个代码树。这些完全是假的提交!这根本不像是单纯的 rebase 错误,而是故意伪造提交者信息,这种行为完全不能接受。在你解释清楚这到底是怎么回事之前,我不会再合并你任何一条提交。你得删掉这个树,并给出一个合理解释。”

甚至,Linus 还直接把这件事同步给了 Linux 基础设施维护者 Konstantin Ryabitsev,要求其立即禁用 Kees 的 kernel.org 账号:

“我认为这种‘玩火’行为在 kernel.org 是绝对不能容忍的。Konstantin,请立即禁用 Kees 的账号,直到事情搞清楚为止。这看起来像是恶意行为。”

330 个“伪造”提交,背后到底是什么?

邮件列表瞬间炸锅,毕竟指控“恶意提交”在 Linux 社区中是非常严重的事情。

在收到质疑后,Kees 自然也不敢怠慢,立刻响应并启动排查。经初步判断,他推测可能是他使用的 SSD 出现故障,导致数据传输出错,从而生成了“损坏的代码树”和“异常的合并记录”。Kees 为此道歉,并承诺将删除受影响的代码树,重新构建一套干净的补丁集再提交。

尽管 Kees 的解释显得合情合理,但 Linus 并不轻易买账。他进一步指出:

“正常的 Git rebase 合并操作应当会重写提交者信息。所以我看到的这种历史重写,几乎不可能是‘无心之过’。至少可以说,这背后有些脚本逻辑已经烂到离谱了。

而且,问题不是一两个提交,而是大量的提交都被重写了——我之前提到的那条只是冰山一角。你那个糟糕的分支里有 330 个 PR 被算到了我头上,但实际上并非来自于我。”

随后,Kees 再度澄清道:“这真不是我有意为之。我怀疑是 SSD 错误 + 手动 rebase 操作 + 某些脚本绕过检查共同导致的。”

真相浮出水面:一场由 b4 工具引发的“自动化乌龙”

在后续的排查与沟通中,Kees、Linus 和 Konstantin 终于找到了“罪魁祸首”——并不是人为蓄意攻击,也不是 Git 本身的问题,而是一款辅助工具 b4 的历史重写操作出了问题。

具体来说,b4 是 Linux 开发流程中常用的邮件补丁打包工具,结合 Git 使用时可大幅简化维护者的 patch 应用流程。可问题在于,Kees 使用的 b4 脚本中调用了 git-filter-repo,在某次历史重写中,意外篡改了大批量的提交元数据,导致提交者信息被重写,从而看起来像是“伪造”了提交。

简而言之:这不是一场人为攻击,而是一场“自动化乌龙”。

对此,Konstantin 也亲自向 Linus 解释了问题所在,并提出解封 Kees 账号:“Linus,我相信他百分之百没有恶意,对于因工具造成的混乱,我深表歉意。我会恢复 Kees 的账户,这样他就能继续工作了。”

而后 Linus 也冷静下来,同意了解封 Kees 账户的提议,并要求 Konstantin 尽快修复 b4 工具的问题:

“所以,真正的危险在于对提交者信息的造假。这是任何标准都不应涉足的领域,也是让我如此愤怒的原因。Konstantin,能否请你修改一下 b4,让它永远都不会重写提交者信息与当前用户不同的提交?”

这场风波最终平息了,但不少开发者却对此次事件展开了一些争论。

部分开发者认为 Linus 反应过激、没必要如此暴怒:

  • “翻看邮件列表后,我觉得 Linus 的回复太不尊重人了。从目前的情况来看,这事只是个意外,没必要一开始就把事情往最坏的方面想。他这种行为只会让人们远离 Linux 内核。试想一下,如果你在 git 分支上犯了错误,却被指试图向内核注入恶意代码,你会怎么想?”

但也有开发者指出,Linus Torvalds 或许脾气急躁,但他作为“看门人”,一直都保持着对流程、规则和开发者责任感的极高要求

  • “Linux 内核项目的运行之所以稳定,并不是因为“没人出错”,而是因为总有人在盯紧每一次提交、每一行代码。”

那么,对于这起事件,你的看法又是什么呢?

参考链接:https://lore.kernel.org/all/CAHk-=wj4a_CvL6-=8gobwScstu-gJpX4XbX__hvcE=e9zaQ_9A@mail.gmail.com/

[330个“假补丁”差点混入主线?Linus Torvalds暴怒开喷:立即封号,不可能是“无心之过”!] https://mp.weixin.qq.com/s/bVRmzCWzt_bEzd_U0vFobQ

Reply Favorite View the author
All Replies
qiye
deepin
2025-06-04 17:29
#1

还好,这守门人还算合格,最怕是领导大手一挥,我相信你。

Reply View the author
aha
deepin
2025-06-04 18:07
#2

慈不掌兵

Linus做的对

Reply View the author
neko
deepin
Ecological co-builder
Resources Team Moderator
2025-06-04 19:00
#3

linux可以说是互联网的基石,严格审查代码是非常有必要的。

Reply View the author
LEARCAT
deepin
2025-06-04 22:03
#4

支持linus虽然严格了一点,但是结果是好的,如果能稍微控制下情绪会更好。

Reply View the author
expskywalker
deepin
2025-06-05 08:43
#5
qiye

还好,这守门人还算合格,最怕是领导大手一挥,我相信你。

万幸,他领导不是川普。

Reply View the author
buyike
deepin
Solutions Team Moderator
2025-06-05 08:45
#6
LEARCAT

支持linus虽然严格了一点,但是结果是好的,如果能稍微控制下情绪会更好。

他那时的情绪才是认真负责该有的样子。

Reply View the author
expskywalker
deepin
2025-06-05 08:53
#7

一个人把关终究精力有限,哪怕是无心之过,把如此重要的系统版本维护把关工作交给及个人去负责潜在隐患是很多的。

从另一个侧面说明要自主研发,安全可控的极端重要性,与其把纯纯的希望寄托在别人掌中,不如捏在自己手里。

Reply View the author
qiye
deepin
2025-06-05 09:25
#8
expskywalker

一个人把关终究精力有限,哪怕是无心之过,把如此重要的系统版本维护把关工作交给及个人去负责潜在隐患是很多的。

从另一个侧面说明要自主研发,安全可控的极端重要性,与其把纯纯的希望寄托在别人掌中,不如捏在自己手里。

所以开源真的安全吗?大家都以为别人检查了,是安全的,但事实上呢?唉。

Reply View the author
流星追月
deepin
2025-06-05 10:54
#9

想都不用想,美国急着往内核埋地雷了,任何手段,这一年出的妖怪事情太多了。

Reply View the author
New Thread

Popular Events

More
国际排名
WHLUG