LWN: WireGuard暂时离开FreeBSD！

关注了就能看到更多这么棒的文章哦～

WireGuard bounces off FreeBSD—for now

By Jake Edge
March 24, 2021
DeepL assisted translation
https://lwn.net/Articles/850098/

WireGuard VPNtunnel 是针对那些需要为自己的网络流量提供安全隧道（secure tunnel）的人提供的一个快速且易于使用的解决方案。该项目早在 2016 年就存在了，但它进入 Linux 的路线有些曲折，直到 5.6 内核（2020 年 3 月发布）才被合入。进入 Linux 的时候当时 WireGuard 开发者 Jason A. Donenfeld 默许让 WireGuard 使用内核中现有的一些加密接口，而不是将他的 Zinc crypto library 合入。这个过程中出现的一些冲突似乎又出现在了最近为几个 BSD 内核添加 WireGuard 支持的过程中。

Complaints

3 月 15 日 Donenfeld 在 WireGuard 邮件列表上的一篇帖子引发了一系列连锁反应：他在帖子中介绍了 FreeBSD 13 中对 WireGuard 支持的现状，当时还处于 release canddiate 阶段。一周前的时候 FreeBSD 开发者 Kyle Evans 在邮件列表中询问了一个 FreeBSD 从 OpenBSD 移植 wireGuard 的 if_wg 实现代码到 user space 的 wireguard-tools 的问题。他同时指出 FreeBSD 13 很快就要发布了。这个即将到来的最后期限引起了许多活动， Donenfeld 在他的邮件中进行了转述：

在接下来的讨论中，我提到了我们真的需要把 if_wg 内核的具体实现做到位。我们在 IRC 上进行了讨论，并一致认为我们应该在发布日期之前想好该怎么做。同时，负责 OpenBSD 实现的 Matt Dunwoodie 也审视了 FreeBSD 的实现情况。在接下来的一个星期里，我们三个人从头到尾地对这个实现进行了彻底重构，我们每个人都推送了代码 commits，并对代码进行了检查以确保其正确性。

他接着详细介绍了在现有移植代码中发现的问题，这些问题是在 Netgate 的要求下完成的。Netgate 是一家生产基于 FreeBSD 的 pfSense 路由器和防火墙的网络安全公司。Donenfeld 描述了在他、Evans 和 Dunwoodie 进行的为期一周的 rework 之前 FreeBSD 代码的状态，让人大开眼界：

这个代码很难看。我能想象到网上会有嘲笑的声音："这些代码就是那种给 C 带来坏名声的典型例子！"。代码中有随意添加的 sleep 用来 "fix" race condition、有的 validation（验证）函数只会返回 true、还有灾难性的加密漏洞、协议中有一整个部分都没有实现、kernel panic、security bypass（绕过安全机制）、各种溢出问题、深藏在加密代码中的随意 printf 语句、极其壮观的缓冲区溢出问题、以及当人们在编写 C 语言时不小心时会犯的几乎所有各种可怕错误。或者，更简单地说，这些代码似乎是典型在代码还没准备好发布时就意外发布出来的产物。本质上就是一个不完整的半成品实现，完全不可能作为生产系统中真正使用的代码。

这篇长长的文章还阐述了 WireGuard 项目背后的一些理念，以及 Donenfeld 的兼容实现方法，这是决定性的做法（decidedly hands-on）。这个做法是 "与传统模式的彻底背离，而且肯定会引起一些老开发者的抱怨"。他在邮件的最后说，他们原本希望能赶上即将发布的 FreeBSD，但最终却没有达到这个目标。Evans 提交了他们所做的改动， 但 FreeBSD "看起来非常有可能" "不得不在发行版中禁用这个模块， 然后在 13.1 版本中重新讨论，而不是在正式发布前的几天时间来合入我们的 fix"。这篇文章引起了科技媒体的报道，进而产生了一系列的影响。

Response

正如我们所猜测的那样，Netgate 对 Donenfeld 所说的话并不特别满意（尤其不满意他的表达方式），并且对没有预先收到这些问题而感到不满意。Netgate 软件工程总监 Scott Long 在公司博客上发布了措辞强烈的回应，他还给 Donenfeld 发了一封电子邮件，本来是私下发的，但是 Donenfeld 则在 WireGuard 邮件列表上公开了回复信息。在博文中，Long 指出，WireGuard 工作早在 2020 年 8 月就已经公开给大家做 review，他对所抱怨的一些内容表达了异议：

遗憾的是，公众讨论也陷入了含糊其辞和诽谤性攻击的陷阱。这就是缺乏透明度、缺乏尊重和自我膨胀所带来的破坏，对大家都没有好处。我们本来希望能有更好的合作，现在我不得不怀疑攻击者的动机。是的，我在这里特意使用了 "攻击者（attacker）"这个词，因为这正是对 Netgate 以及 FreeBSD 和 pfSense 社区的攻击。大家当心那些说自己懂得所有东西的人。我也对那些发表含糊其辞的声明和一概而论的指责的人的诚信表示怀疑。

[……]本来可以遵循正常的、互相充分理解的安全披露流程来使这个问题通过正常渠道得到快速而有效地处理。我们目前仍未看到所谓的具体问题的完整描述。他们选择进行完整的重写，这个行为使得我们无法确认他们真的在 fix 哪些问题， 而且他们还没有通过正常的 FreeBSD Phabricator 流程来提交他们的代码进行 review。尽管如此，我们还是期待着能看到 bug 报告以及随后通过 review 流程来评估代码。代码开发是一个迭代的过程，也是我们不断努力改进的过程。最终，我们都会受益。

就 Evans 而言，他对自己在这个混乱情况中的角色感到不满，于是在 3 月 16 日宣布他将从 FreeBSD 中移除 WireGuard，直到后面发布新版本之后再说。他和其他一些开发者计划后续继续进行这项工作：

问题是，这项工作是一个会有很严重的安全影响的驱动程序。仅仅有 "三个开发者在进行开发和修改" 对于 review 流程来说还是不太够的。

随后，他在 3 月 18 日发文完全退出 wireguard-freebsd 项目，同时也对 Donenfeld 的原帖进行了回应。他说，他并不 "欣赏你将这个初步沟通内容公布出来的方式"，并认为有些抱怨被夸大了，不过他也承认现有代码中确实存在多个问题。除此以外：

我以开发者的身份而非官方的身份建议，我们不能将 if_wg 包含在未来的任何版本中。如果我们无法做到及时发布安全建议，那么我们就不能把我们的用户放到这样危险的境地里。Ports 是一个好地方，安全问题可以在这里得到迅速的解决，而且更符合 WireGuard 项目选择的处理方式。

目前，开发将继续在 wireguard-freebsd Git 仓库中进行，但听起来，不会很快回到 FreeBSD 内核中了。3月 22 日，Warner Losh 在 freebsd-hackers 邮件列表中放出了 FreeBSD 核心团队关于 "WireGuard 争议"的消息：

Core 无条件地重视所有贡献者的工作， 并寻求一种合作、尊重和协作的文化。过去一周关于 WireGuard 的公开言论不符合这些标准，如果不加以制止，会对我们的社区造成损害。因此，FreeBSD 的 WireGuard 开发现在将在基础系统（base system）之外进行。对于那些希望评估、 测试或实验 WireGuard 的用户，可以通过 ports 和 package system 来获取到 snapshot 版本。

NetBSD

正如 Donenfeld 的原帖中所提到的，NetBSD 也曾努力在 NetBSD 中增加 WireGuard 的支持，但似乎并不完全顺利。2020 年 8 月，Donenfeld 在 NetBSD 的 tech-kern 和 tech-net 邮件列表上发起的一个邮件讨论也同样对现有的 WireGuard 实现代码提出了批评，他要求将现有的代码 revert 掉，来讨论一下后续的正确的前进道路是什么。他提出与 Taylor R Campbell 合作，Compbell 在 2018 年的时候接手了一些由 Ryota Ozaki 写的代码，而"今年我 review 的时候，看到这些代码的状态似乎还不错，我看到了一些小问题，所以我顺手修掉就合并了"。

在那个邮件讨论中，Campbell 和其他人反复要求 Donenfeld 描述他说他发现的问题，但 Donenfeld 并不打算这么做：

并不是说这里那里有些 bug，也并不是说可以用 TODO list 来列出来的一些小错误或者优化点，或者那种人们通常会说 "好了，骨架已经有了，可以先加到代码树里，后续逐步清理来完成逐步进化" 的那种情况。而是说，这个基础就是不完整的，目前的形式不足以被合入代码库中。

[……]这里正确的做法是 revert 掉这部分代码，然后我们再来评估我们要往哪个方向发展，是对 Ozaki-san 的代码进行全面拆解，还是干脆简单地将 OpenBSD 代码移植过来。

似乎 Campbell 和 Donenfeld 从来没有达成这个共识。Donenfeld 在最初的 FreeBSD 公告中说他希望 "能够很快的向 NetBSD 开发者提供类似的帮助"。这里的部分问题可能在于 Donenfeld 希望进行的 review 的类型，他谈到了他和 Dunwoodie 在一年多的时间里为了使 OpenBSD 中的代码成型所做的那些工作（"持续的代码 review、knowledge transfers，甚至需要的时候他会出现在我家来一起阅读代码"）。Matt Macy, 也是那个饱受诟病的 FreeBSD 版本的作者, 在 FreeBSD 的 bug 报告中也提到了类似的要求:

Jason 坚持认为代码需要由他来 review, 但他不会花任何时间来 review 代码, 除非我真的坐在那里和他直接交流。OpenBSD 的开发人员似乎已经花了几十个小时和他在一起 review。然而, 我根本没有时间或兴趣去做这些。我不知道 FreeBSD 社区里有谁有 crypto 背景可以来 review 这些协议中的 bit 定义，谁有精力这样做啊。

从各方面来看，WireGuard 本身就是一个优秀的 VPN 解决方案，但似乎与通常的网络协议的做法不同，通常的网络协议都是根据一个规范来独立做出多个实现，而 WireGuard 需要受到特殊的对待。Donenfeld 有理由为自己的成就感到骄傲，但他对其他版本的实现的要求似乎太过僵化了，至少对一些社区来说是这么个情况。正如我们在几个不同的操作系统项目（Linux、FreeBSD、NetBSD）中看到的那样，Donenfeld 经常期望其他那些规模更大的项目要符合他的严格标准和方法。最终，这种态度可能会让更多的人感到不满意，而不仅仅是那些老程序员们（graybeards）。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～