🏠

愤怒的Rsync

原文: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0

作者: Andrew Tridgell

翻译: 费米 fermi@dscli.io https://github.com/dscli/dscli

—

我很久以前就不写博客了（除了偶尔写点关于 ArduPilot 的东西），我习惯只 管写代码，希望人们觉得有用就好。所以写这篇文章感觉有点奇怪，但鉴于最近 收到了大量愤怒的帖子，我想也许该说点什么。

和许多开源包的维护者一样，作为 rsync 的维护者，我最近被大量安全报告淹 没了。其中很多是 AI 生成的——不过不全是，有些报告是经过非常仔细和高质 量的人工分析的。

随着这股洪流越来越猛，我意识到必须大大提升 rsync 的防御能力——我们需 要更全面的测试套件、代码覆盖率分析、在更多平台上做 CI 测试、主动而彻底 地扫描可能的安全问题（这样我至少能在别人发现之前找到一部分！），还要增 加大量纵深防御加固技术。这些都是巨大的工作量。我已经退休了（虽然我妻子 可能不这么认为！），我宁愿出海航行，也不想处理 rsync 的安全问题。所以 我借助了一些 AI 工具来帮忙。我对此毫不后悔，尽管从反 AI 的愤怒风暴来看， 很多人觉得我哪怕只是考虑用 AI，就该被吊起来抽。

要回应所有对我咬牙切齿的指责，那得花太长时间了，所以这里只举几个例子：

——我把 rsync 的测试套件从旧的 shell 脚本重写成了 Python。设计是我自 己做的（而且对这个设计我相当满意），但繁重的编码工作用了 Claude，并用 Codex 和 Gemini 交叉检查。我不是简单地「用 vibe coding 把测试套件转成 Python」。我是一个有 40 年经验的软件工程师——是的，我很老！——所以我 会先做设计，有一个验证计划，然后用 AI 工具来做苦力活，因为它们擅长这个。 我自己审查了每一部分，花了大把 CI 时间把它做对（后来我改用本地虚拟机做 大部分测试，以减少 CI 等待时间¹）。你在提交历史中看到的 「co-authored by Claude」只是冰山一角。

——对于那些说「我是某某大学的博士，我告诉你 LLM 只是靠概率瞎猜的工具，什么都 瞎编，用了它世界就会崩溃」的人，我要告诉你：你过时了。 过去几个月里发生了天翻地覆的变化。IT 安全领域——维护软件面对报告洪流 这件事——在过去几周里已经彻底改变了。你去年学到的关于这些东西的知识， 可能已经像是另一个星球的事了。哦对了，我也有计算机科学博士学位，而且我 确实在神经网络上做过不少工作——是的，我那个时代的所有知识也完全过时了。 另外，没有人知道人类智能是否也只是更细粒度的随机预测。也许有一天我们会 搞清楚，也许永远不会。底线是：我确实知道——至少大致知道——LLM 的工作 原理，但这并不妨碍它们有用。这确实意味着你必须谨慎；而我已经很谨慎了， 至少在我渴望出海航行、不想处理那帮所谓互联网专家的垃圾信息的前提下，已 经尽可能谨慎了。

——是的，rsync 3.4.3 版本在某些使用场景下确实出现了回归问题。我有意在 该版本中优先修复安全问题，结果一些有效但不太常见的使用场景受到了波及。 这些场景既没有被现有的 rsync 测试套件覆盖，也没有被我的手动测试覆盖——是 的，我自己也用 rsync，不只是开发它。我正在逐个处理这些回归问题，也感谢 所有在 GitHub 仓库上提交 issue 或 PR 的人。我都在看，即使不一定能迅速 回复。如果你的 rsync 使用场景受到了影响，我道歉。如果你不介意安全风险， 当然可以继续用旧版本。

——对于那些说「天哪，他居然没用 pytest，他到底懂不懂啊！」的人：我在 其他项目中大量使用过 pytest。但在这里它并不合适。这个测试套件有些需求 用 pytest 很难实现——至少基于我的使用经验——所以我针对具体任务设计了 合适的方法。我这辈子都在做这样的事：经常因为现有方法不太对路而创造新方 法。我个人认为这本身就是件好事。

现在说说未来，因为还远未结束。安全报告继续涌来。我目前正在处理一批 CVE。 幸运的是，一些拥有出色系统开发技能和安全知识的优秀开发者加入了我。其中 有些人之所以引起我的注意，部分原因正是最近这场愤怒风暴——所以愤怒的乌 云也有银边。下次发布时，请注意看一些优秀新贡献者的致谢名单。

我现在正在犹豫：是发布一个缓和部分回归问题的 3.4.4，还是直接按计划推出 改动更大的 3.5.0。3.5 将在 rsync 安全性上大幅提高标准，但改动巨大。需 要这么大的改动集，正是我重写测试套件的主要动力——没有真正全面的测试套 件，你不可能对像 rsync 这样的软件进行快速的大规模改动。我曾想先在 master 分支上公开测试套件的核心结构，但鉴于由此引发的愤怒，也许这不是 个好主意。不管怎样，新的测试套件已经帮了大忙，我还准备了一大堆安全相关 的测试——等 3.5 发布时大家就能看到了。

我希望——也许太天真了——通过目前的努力，我能赶在前面，让洪流变成涓涓 细流，然后干涸。也许我只是在做梦。

现在，如果那些发怒的人中有人愿意审查我发布的代码，提出建设性的批评，那 就太好了！如果你们只想继续发泄愤怒，我相信你们能在互联网的某个角落找到 欢迎你们的地方。

至于那些说「我要为 XXX 平台打包 openrsync，用那个代替 rsync！」的人——我 觉得挺有意思的。如果你真要走那条路，我建议你试试用新的 rsync 测试套件 跑一下 openrsync——如果你能忍受 AI 帮助写的代码的话。我今天试了一下， openrsync 在 98 个测试中失败了 85 个，所以我相信你很快就能把它搞定的。 运行方式：

./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp

当然，很多失败只是因为 openrsync 缺少某些功能，但不管怎么说，这结果不 太好看。

最后，前两天我偶然看到这个页面 https://www.tridge.com ，忍不住笑了出来。 看来也许我这辈子一直都是个机器人——也许这就是为什么我不像别人那样讨厌 AI 工具的原因²。

Andrew Tridgell Written by Andrew Tridgell