LWN: Python cryptography, Rust, and Gentoo
关注了就能看到更多这么棒的文章哦～
Python cryptography, Rust, and Gentoo
By Jake Edge
February 10, 2021
DeepL assisted translation
https://lwn.net/Articles/845535/
总有人在使用一些现在不那么流行的老架构，而各大项目通常会针对更多的主流用户和系统，因此这两者之间总是有矛盾的。从很多地方都可以看出，我们的社区已经被 GCC 所支持的庞大架构数量给宠坏了，但是很多新出现的软件并不是用 C 语言编写的，并且还有很多软件正在从 C 语言迁移到新的语言上去。Rust 语言，就是这些软件的一个常见选择。但它是用 LLVM 构建的，其支持的架构比 GCC 和 Linux 所支持的体系架构要少。所以，这里就有一个问题，这些上了年纪的、不能支持 Rusty 的体系架构，对于未开的开发工作能有多大影响。从好几个地方看出来，似乎都不会有很大影响。
最新一个问题出现在 Gentoo 开发邮件列表上。Michał Górny 指出，Python 加密库（cryptography library）已经开始用 Rust 替换了部分 C 代码，因此现在要编译这个库就需要 Rust。由于 Gentoo Portage 这个 package 管理器会间接依赖于 cryptography library，"因此我们可能会不得不放弃支持那些无法支持 Rust 的架构"。他列出了 Rust 所不支持的五个架构（alpha、hppa、ia64、m68k 和 s390），另外还有五个架构是 Rust 可以支持但是 Gentoo 中还没有支持 Rust package（mips、32 位 ppc、sparc、s390x 和 riscv）。
Górny 在 cryptography 的 GitHub 仓库中提交了一个 bug，"但显然 upstream 认为 Rust 的'内存安全（memory safety）'比起某些人不能使用这个 package 来说更加重要"。不出所料，library 的开发者们对事情的看法通常跟发行版开发者们会有些不同。但关于这个 bug 还是有了无数的评论，这清楚表明许多人对于 2 月 7 日发布的 cryptography 3.4 版本中的变化感到惊讶。
library 的 contributor 之一 Christian Heimes 明确表示，他们不会取消对 Rust 的依赖。他指出了一个 FAQ 条目，其中介绍了如何禁用 Rust 来构建库的 FAQ 条目，但也指出当 cryptography 3.5 发布时，这个方法也不再有效。他还指出，Rust 只是构建时需要依赖，在运行时就不再需要了。
但在这个 bug report 中，有多人抱怨改为依赖 Rust 这件事并没有预先广而告之。有人认为项目遵循的 semantic versioning（版本定义，https://semver.org/ ），就意味着这种变化不应该在 minor version 中出现。事实证明，该项目有自己的版本定义方案，它是允许这种变化的（其实 semantic versioning 也是允许）。但 Heimes 确实也认为之前关于这个改动的沟通可能还不够充分。他指出了 2020 年 7 月的一个 PR（pull request）拉动请求和 12 月 22 日 cryptography-dev 邮件列表上的公告，这些都是 Alex Gaynor 发布的，从而让这个问题提上了议程。按照这些链接找到了很多关于这个想法的讨论，但很明显，即将进行这个改动的计划并没有传递到 cryptography 社区之外。部分原因可能是由于用户通常拿到 cryptography library 的方式问题，正如 Heimes 所解释的：
大多数用户要么使用 binary wheels (macOS x86_64, glibc Linux x86_64 + aarch64, Windows X86 + X86_64 等平台上的主要用法)，要么使用 Linux 发行版中的软件包。binary wheels 并不需要额外安装 Rust 库。只有 Alpine (musl)、BSD、以及其他硬件平台和发行版上的用户受到影响。
许多 Alpine Linux 用户受到这个改动的影响，其中一些人在评论中大声地抱怨，他们有持续集成和部署系统（CI/CD），也会经常更新和构建相关的包。不过在这种情况下，因为 Rust 编译器缺失，导致其中许多工作都出错了。不过最新的 Alpine 版本确实已经加上了 Rust 支持，所以这些系统上的修复可能是很简单的。
但对于那些目前不支持 Rust，而且事实上很可能永远也不会支持 Rust 的架构来说，除了对 cryptography 进行 fork 来维护一个基于 C 预言的版本之外，没有其他的办法了。Górny 在 gentoo-dev 的讨论邮件中以及上面提到的这个 bug report 中提出了这个建议。其他人也有类似的想法，但目前还不清楚是否真的有足够的资源支持这种新的 fork 代码开发。Python 3.8 和 3.9 发行经理 Łukasz Langa 向 Górny (和其他人) 挑战说，欢迎他继续进行 fork 工作："我非常欢迎你这么做。请把你的资金和时间按你所说的投入进来。一年后我们再看看情况如何。"
Langa 还指出，cryptography 的维护者也都是志愿者，这意味着他们可以把自己的精力分配到任何他们想做的方向，即使这会让某些其他志愿者感到麻烦。除此之外，进行这个改动是有原因的：
在我开始讲之前，我想提醒大家，安全是一个数字游戏。如果 cryptography 维护者可以通过改用现代的内存安全的语言来帮助 90% 的用户，如果仅仅因为剩下的 10% 的用户在用那些无法运行 Rust 编译器的少见平台而放弃改变，这就是不负责任的做法。
[……]你期望那些志愿者让他们的关注于安全的项目来继续依赖那些本质上就不安全的技术，仅仅因为这会使你自己的工作更容易做。而你的目标和要求就不符合 cryptography 库维护者的目标和计划了。对你来说很不幸，但真的就是这么回事。
这个 bug 下面的讨论持续了很多。例如，CI/CD 系统在处理依赖关系时针对 cryptography 这类库的版本处理，是有一些问题需要解决的。但也有很多人对于开发者 "强行" 将自己选择的 Rust 强加给别人，以及 "破坏" 了许多系统的行为进行了抨击。开发者们则试图继续帮助那些拥有可以运行 Rust 的系统的用户，而对于其他系统只能耸耸肩表示无能为力了。
最终吵翻了天，然后除了项目贡献者之外，其他任何人都不允许再发表评论。而 Gaynor 认为这些问题对于这些那些旧平台来说是不可避免的。关闭了这个讨论后，他总结了一下讨论过的内容，并重申 cryptography 开发者不会因为那些不支持 Rust 的平台而改变主意。
回到 Gentoo 这一边，调查下来 Portage 之所以依赖 cryptography 是因为它使用了 urllib3 和 requests。Gentoo 中的这两个软件包是依赖 cryptography 的，但实际上并不需要。为了解决这个问题，合并了一个 pull request (https://github.com/gentoo/gentoo/pull/19383)，这样就避免了对 Gentoo 系统非常重要的 Portage 出现问题。
至少现在是绕过了这个问题。但 Górny 担心的是，发行版的测试中使用的 trustme TLS test-certificate generator 中确实需要 cryptography，所以有些平台上可能无法进行完整测试。另一方面 cryptography 的开发者已经决定会创建一个 3.3 LTS 版本，在其中维护引入 Rust 之前的版本，直到 2021 年底为止。不过，在该版本中只会对 CVE 进行修复。
但 Górny 还有一个更大的担心。他认为，Python 本身未来的某个版本有可能会开始需要 Rust，尽管还不完全清楚他的判断依据是什么。这对没有 Rust 的架构上的 Gentoo 平台来说将是毁灭性的，因为 Genntoo 发行版严重依赖 Python。其他发行版也会有问题，但唯一真正的解决方案是让 LLVM (因此 Rust 也就能得到支持) 在这些架构上能正常工作，或者让 Rust 的 gccrs GCC front-end (或类似的一些项目) 取得进一步的进展。
虽然 Python 本身很可能不会完全切换到 Rust 去，但很明显，Rust 正变得越来越流行。如果它能 "无处不在" 地正常运行，那当然是最好了，但要达到这个目标还需要一些艰苦的努力。LLVM 的开发者对支持新的架构一直有些戒心，除非他们能确信这个架构会在很长时间都会有人支持。这是可以理解的，但却让问题变得更加糟糕。
早在 2018 年，我们就在 Debian 和 librsvg 上看到了类似于 Gentoo 的问题，而且我们很可能会看到它在未来几年内反复出现、频繁出现。各个项目去使用新的工具，这是很合理的需求，而项目对支持古老架构不感兴趣也不是没有道理的。当然这是很不幸的，但我们就是总会面临这些两难问题。也许，运气好的话，这种困境今后会有所改变。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～