dbaplus社群

他守护全球数据备份30年,却因用AI工具堵漏洞,成了众矢之的……

8.5内容质量
他守护全球数据备份30年,却因用AI工具堵漏洞,成了众矢之的……

TL;DR · AI 摘要

Andrew Tridgell因用AI工具修复rsync安全漏洞引发争议,其开发的rsync算法影响全球数据备份。

核心要点

  • rsync算法通过指纹匹配实现增量传输,使4GB文件修改后几秒即可传输
  • Tridgell使用AI工具修复漏洞后,引发依赖rsync的用户群体争议
  • Git的诞生源于Tridgell逆向分析BitKeeper协议的行为

结构提纲

按章节快速跳转。

  1. Andrew Tridgell因使用AI工具修复rsync漏洞引发争议,其代码影响全球数据备份系统。

  2. 1996年开发的rsync算法通过指纹匹配实现增量传输,被主流系统预装使用。

  3. Tridgell逆向分析BitKeeper协议的行为直接催生了Git版本控制系统的诞生。

  4. 2024年发现6个高危漏洞,AI修复方案引发用户群体对维护方式的质疑。

  5. Tridgell重启维护后使用AI工具修复漏洞,导致依赖方要求追究其责任。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • rsync与Andrew Tridgell
    • 核心贡献
      • rsync增量传输算法
      • Samba文件共享协议
      • Git版本控制系统起源
    • 安全事件
      • 2024年6个高危漏洞
      • AI修复工具争议
      • Google验证漏洞可利用性

金句 / Highlights

值得收藏与分享的关键句。

#rsync#安全漏洞#AI工具#开源软件#数据备份
打开原文

他本来已经退休了,却为挽救全球所有备份代码再度出山,可那些依赖他代码的人因 不满他拯救的方式反过来指责他。即便如此,他也从未有过一丝后悔。

他的代码,几乎在全球每一台Linux服务器上跑着备份任务;他发明的同步算法,就连macOS内部也在使用。本来他早已退休,想去出海航行。

可现实却是,他的收件箱里塞满了关于rsync的安全漏洞报告。rsync是他三十年前开发的软件。大部分报告都是机器自动生成的无效信息,只有少数是真实漏洞。而他必须逐一阅读,才能分辨出哪些是有用、哪些是无效的。

于是,他拿起当初让他不堪重负的同类工具解决了这个问题。

效果立竿见影。

可没过几天,那些依赖他代码的人,反倒因为他解决问题的方式,想要追究他的责任。

一、隐藏在所有备份里的1996年算法

1996年,澳大利亚国立大学的一名博士生遇到了一个听起来平平无奇,却最终影响到全世界的问题:如何在网速很慢的情况下,只传文件改动的部分,不用重发整个文件?

这名博士生就是 Andrew Tridgell,朋友和邮件列表里的人都叫他 “tridge”。他和Paul Mackerras一同设计出了 rsync算法,而这个算法的核心,是一个无比巧妙的思路。

两台电脑上各存有一份同一文件的不同版本。接收方先把自己的文件切分成数据块,再为每个块计算出一个小指纹。这个指纹是根据数据块里的字节生成的短小数字,只要有一个字节改动,指纹就会变。接收方只需要把这些指纹发过去就行。发送方对照自己的文件,匹配出已有的相同数据块,只传输发生变化的字节。一个4GB的文件,哪怕只改了一行内容,几秒钟就能传完,而不是几小时。你的备份在你睡醒前就已经完成了。

Image 1: Image
Image 1: Image

图片来源:作者,rsync如何通过仅发送已更改的字节来复制已更改的文件

这套机制如今已预装在所有主流Linux发行版和macOS系统中。我从21世纪初就开始部署Linux系统,而我搭建过的备份流程、部署脚本、数据迁移任务,无一例外都会在某个环节用到rsync。你大概率也是如此,只是从来不必知道它的名字而已。

二、一个不小心启动了Git的人

rsync还只是个开始,Tridgell还编写了Samba的最初版本。正是这款软件,让Linux和Windows系统能够互相共享文件。

2005年,他干了一件事,从此整个行业的代码管理方式都被改写了……

当时,Linux内核团队使用一款名为 BitKeeper 的商业工具来管理所有源码变更。这款工具是闭源软件,归BitMover公司所有,不过公司允许内核开发者免费使用。但这份免费许可附带一个苛刻条件:不允许对这个软件逆向工程,也不能开发同类竞品。

Tridgell想开发一款免费的替代工具,让Linux这样至关重要的项目不必再依赖某家公司。为了开发出替代工具,他首先得搞清楚BitKeeper是如何通过网络与服务器通信的。而他用的办法简单得近乎好笑:他连上一台BitKeeper服务器,输入了一个词 :help。这是询问任何系统 “能做什么” 的通用方式。服务器随即返回了一串可用命令列表,就是这么简单。他一问,软件就自己把底细交代得明明白白。

在BitMover看来,这种行为已经构成违约。以这种方式连接并试探服务器,正是免费许可协议明令禁止的行为。于是该公司当即撤销了所有Linux开发者的免费使用权限。一夜之间,内核开发团队失去了代码管理工具。Linus花了数周时间,试图从中调停和解。调停失败后,他亲自动手,只用几天就开发出了一款替代工具,并将其命名为Git。

Linus在一个公开论坛上发了一篇题为《伪善是人类最恶劣的品性》的 帖子抨击Tridgell,称他“坑了别人”,并 且“只因自己有能力,就毁掉了一个新颖且出色的软件”。[1]而Tridgell以及支持他的自由软件开发者则认为,他只是像别的工程师那样分析一个网络协议,这与当年开发Samba时所做的工作并没有什么不同。双方观点都有据可查,这场争执最终也没有一个明确的定论。但双方都认可一个结果:如今每一位执行git commit的开发者所使用的这款工具,正是因这场纷争才得以诞生。 所以我说Andrew Tridgell是这个领域的传奇人物,绝非过誉。他整个职业生涯,都在搭建别人赖以运转的底层基础软件。用他自己的话说:“我是一名拥有40年经验的软件工程师(没错,我年纪确实很大了!)”

2002年,Wayne Davison接手成为rsync的主要维护者,Tridgell则去做了其它工作。Davison低调地维护了二十年,没有出过重大故障,也没有任何风波。好的基础实施本就该如此可靠又低调。

但这位本想安心出海航行的退休老人却重新回归了。他在2025年1月14日发布了第一个版本,署名是:Andrew Tridgell / rsync 维护者 (再次!)

沉寂二十二年后,他再度归来。

究竟是什么原因把他拉回了这个在很多用户出生之前就已移交出去的项目?

三、信守承诺,但实际暗藏危机

他是因为Wayne Davison回来的。

Davison独自维护rsync二十二年,到了2024年4月,各种生活琐事缠身,他实在分身乏术,于是主动联系了Tridgell。“因为各种生活事务占满了我的时间,我联系了Tridge。”Davison写道。这一通电话,兑现了多年前的一个承诺。早些时候,Tridgell就跟他说过,如果哪天撑不住了就打电话。Davison真的打通了这个电话,Tridgell也遵守了诺言,回来接手了这份二十二年前就约好的交接。但他完全不知道,代码里已经有隐患正等着他。

那场风波还要再过几个月才会爆发。2024年末,Google Cloud的三名安全研究员Simon Scannell、Pedro Gallegos 和Jasiel Spelman提交了一份非公开报告。他们在rsync中发现了五个安全漏洞,而来自Loqpa公司的Aleksei Gorban又报告了第六个。总计六个漏洞,其中Google发现的两个漏洞,一旦组合利用,便是最危险的那种。

假设一家公司运行着一台rsync服务器,用来接收每日夜间的备份数据。攻击者只要像普通客户端一样连上这台服务器就行。本来每天晚上正常的备份任务也会建立同样的连接,但rsync存在一个堆缓冲区溢出漏洞,危险等级高达9.8分(满分 10 分)。攻击者只要连上服务器,就能直接运行自己的代码,不需要密码,也不用管理员权限。Google的研究人员已经在Debian 12上成功实现了这种攻击,证明漏洞真实可利用。

他回归后的第一件事,就是救火。2025年1月14日,他发布了rsync 3.4.0,一次性修复了全部漏洞。可这个补丁只安稳撑了一天。他改动的某处代码引发了新问题,第二天一早,他又紧急推出3.4.1,修补自己上一版的补丁。每个赶在截止日期前发布安全修复的人,都经历过这种事:赶时间快速上线,结果补丁本身还需要再补。这就是紧急修复漏洞时最真实的常态。

可随后,漏洞报告还在接二连三地来……而且问题的性质,也开始变了。

四、来自一位并不存在的资深工程师的报告

Tridgell写道:“和很多开源软件开发者一样,我作为rsync的维护者,最近被大量的安全报告淹没了。”[2]

这批报告还出现了一个新特点。他说:“其中很多都是AI生成的,不过也不是全部,有些还是值得注意的。”

有人用扫描工具把一个大语言模型对准了rsync源码。模型自动生成安全报告、提交上去,一遍又一遍,全程没人看一眼那些输出。维护者打开收件箱,看到一堆看起来很专业的报告:格式规范、引用的函数在代码里确实存在。有些真的指出了漏洞,但绝大多数描述的是代码里根本不存在的行为,写得像模像样,仿佛出自一位根本不存在的资深工程师。每一份报告都必须手动打开、阅读、逐行核对源码,确认是真是假。因为他一旦漏掉其中一份,那一份偏偏就可能是真的。

这样筛选排查并非没有代价。每花一小时排除AI生成的无效报告,就少了一小时去修复真正的问题。他说:“随着这类报告越来越泛滥,我意识到必须提高防御门槛了。”

五、三个AI在疯狂输出,只有一个人在把关

rsync老旧、运行稳定,但几乎没怎么测试过。它的测试套件只是一堆shell脚本,既没有真正的代码覆盖率分析,也没有跨平台的持续集成。对于一个支撑着全球几乎所有Linux备份和镜像的工具来说,这点防护实在太单薄了。

于是Tridgell重新加固了防护。用他的话说,这个项目 “需要更完善的测试套件、代码覆盖率分析、在更多平台上做持续集成测试……还要加入大量深度防御加固技术。”

纵深防御是一种比rsync还古老的安全理念:设置多层独立防护,就算攻破一层也无法直接入侵系统。没有任何一道检查是万无一失的,所以要让攻击者必须连破数关才行。Tridgell把测试套件从Shell脚本全部重写成Python,增加了代码覆盖率检测,并搭建了持续集成,在更多系统上跑测试。

他用AI来处理重复性的机械工作,而且明确说了用哪些工具、怎么用。

用他的话讲:“我主要用Claude,同时用Codex和Gemini交叉校验,来做这些繁琐的基础工作。”Claude是主力工具,Codex和Gemini用来辅助核对。然后是人工环节:“所有内容我都亲自逐一审查,并且跑了大量CI测试,确保准确无误。”

他对提交记录所代表的含义,划清了明确界限。“你在提交历史里看到的「Co-authored-by: Claude」,只不过是软件工程的冰山一角。”代码差异并不会体现背后的设计思路、判断、审查,也看不出他试过多少种方法、放弃了多少种,最后才敲定能用的方案。他写道:“因为原有方案不够完善,所以我要经常重新设计。”AI负责敲代码,工程师才决定哪些值得保留。

只要写过线上生产代码,你就清楚真正难的是哪一部分,反正从来都不是敲键盘。

Image 2: Image
Image 2: Image

图片来源:作者,AI 如何用报告淹没 rsync,以及 Tridgell 如何使用 AI 来强化它

这次加固版本于2026年5月20日发布,也就是rsync 3.4.3,又修复了六个安全漏洞。Tridgell亲自在oss-security邮件列表发布公告:每个漏洞单独打了补丁,并公开了安全说明。这次发布很谨慎,完全按规范流程来,防护能力迅速提升。过去十年里,很多用户们早把rsync用出了各种稀奇古怪的花样,很多用法几乎没人见过。而新版代码刚一上线,就把这些边缘场景全部揪了出来,结果搞得大家叫苦不迭。

六、完成即神圣,而后署名:与Claude联合开发

在某个地方,有个团队在跑一个备份脚本,这个脚本已经九年没人动过了。它调用rsync时带了一堆参数,这些参数组合几乎没别的人会用。这个任务每晚都无人值守,自动运行。升级到3.4.3之后,一向都能顺利完成的文件拷贝突然报了个错,团队里谁都没见过这个错误。备份没跑完,早班人员看到日志里的报错,一上班就得调试这个以前从不用操心的工具。 这就是边缘场景出现兼容问题给用户带来的真实影响。常见的用法都跑得通,但那些多年积累下来的冷门参数和特殊配置,新代码一跑就崩。

社区的愤怒来得很快,大家纷纷盯着提交历史看。2026年5月到6月初,带有「Co-authored-by: Claude」标识的提交越来越多,足足有几十个,覆盖CI工作流、测试框架、版本兼容校验等等。这对于一直把rsync当作“已完成、神圣不可侵犯”的社区来说,简直是冒犯。

5月30日,有人在GitHub上提了一个issue,标题原话是:“求你别瞎折腾毁了这个软件。”[3]

七、替代方案表现糟糕:98项测试中85项不通过

接着,按照开源界的惯例,大家开始纷纷提替代方案了。

这个替代方案是 openrsync,由Kristaps Dzonsons为OpenBSD项目开发,采用BSD协议重新实现。它没有基于原GPL代码分叉,而是从零重写了rsync的功能,这也是苹果能直接集成它的原因。2024 年,macOS Sequoia quietly切换到openrsync,以此避开GPLv3协议。各发行版维护者也开始讨论要不要效仿苹果。作为大量Docker容器基础镜像的Alpine Linux,现在已经打包了openrsync,也在考虑要不要换成它。

但这些愤怒的讨论里,没人先提这件事。Tridgell用他靠AI搭建的全新Python测试套件去测了openrsync。结果:98 个测试里挂了85个,这个“干净”的替代方案只通过了13个。

他说得很客观:很多失败只是功能缺失,不是代码bug。openrsync并没有实现rsync的全部能力。可即便如此,这个结果依然极具冲击力。批评者拿来当作rsync衰败证据的那套测试,恰恰也暴露了:openrsync还差得很远。

八、“我绝对不后悔”

2026年6月3日,Tridgell发表了一篇题为“rsync和愤怒”的帖子。

他没有道歉。

他坦然承认了版本兼容问题,没有回避。同时详细说明了自己使用AI的过程、重写测试、代码覆盖率检测、安全加固工作,以及哪些是自己设计、哪些交由AI完成。他态度坚定、毫不含糊:“我一点都不后悔这么做,” 他写道,“尽管从这场反对AI的舆论风暴来看,很多人恨不得把我吊起来狠狠鞭打。”

我自己也做过好几次同样的决定,只不过规模小一些,两种结果都经历过。当系统已经着火,而你是唯一拿着水管的人时,你会抓住一切能出水的东西。有时你拿起的工具会把地毯弄得一团糟,接下来一个月都要去收拾。但你依然不会后悔当初伸手去拿,因为不抓的话,你就只能眼睁睁看着房子烧掉,同时还在一遍遍读那些关于烟雾的报告。

他现在面临两条路:要么发布3.4.4,先修复兼容问题、稳住边缘场景;要么直接推出3.5.0,更进一步,通过更大幅度的改动封堵更多漏洞,加固安全。

这种兼容问题并非新鲜事。早在使用Claude之前,rsync就存在这类问题,之后也一样。一年多前发布的rsync 3.4.0也是如此:上线后又需要3.4.1来修复故障,当时完全没用到AI。这款工具并没有因为引入AI就变得草率。赶工期的软件开发,本来就是这样。

Image 3: Image
Image 3: Image

图片来源:作者,之前所有人工智能和开源维护者故事的颠倒

九、那个撑着你所有备份的“幕后老将”

其实你从没主动选过rsync。从你买下Mac、或是装好Linux的那一刻起,它就已经在为你服务了。无论你有没有亲手敲过这个命令,它都在默默守护着你的备份。

这位维护者在业余时间里,凭一己之力维持着项目运转。而那些依赖着他成果的人,却反过来指责他、说他该受罚。

他并不后悔。

在房子着火时,他拼命救火,而我们其他人却还在为那个水桶是什么牌子而争论不休。

真正值得反思的是:三十多年过去,全世界的备份安全居然还压在一位退休开发者的肩上。而年轻一代却还在往虚拟足球球员身上砸钱,只为在线上赢几场比赛。

**>>>> 参考资料**

  • [1]https://www.realworldtech.com/forum/?threadid=49168&curpostid=49169
  • [2] https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
  • [3] https://github.com/RsyncProject/rsync/issues/929

作者丨Can Artuc 编译丨dbaplus社群 来源丨网址:https://canartuc.medium.com/his-code-backs-up-the-world-now-the-internet-wants-him-flogged-fb73c6ce050c dbaplus社群欢迎广大技术人员投稿,投稿邮箱:[email protected]Image 4: Image