330个“假补丁”差点混入主线?Linus Torvalds暴怒开喷:立即封号,不可能是“无心之过”
日期:2025-06-05 13:53:04 / 人气:4
"众所周知,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 的原始 PR,右边是伪造的 PR)
愤怒之下,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/
"
在上周末 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 的原始 PR,右边是伪造的 PR)
愤怒之下,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/
"
作者:安信14娱乐平台官网
新闻资讯 News
- 家办CIO的生存法则:从"不亏钱...06-05
- 李斌的盈利算盘,打得更响了 "即...06-05
- 谁的娃哈哈?宗馥莉的操盘术06-05
- 5月销量盘点:零跑三连冠,华为历...06-05