LWN: Python cryptography, Rust, and Gentoo
關(guān)注了就能看到更多這么棒的文章哦～
Python cryptography, Rust, and Gentoo
By Jake Edge
February 10, 2021
DeepL assisted translation
https://lwn.net/Articles/845535/
總有人在使用一些現(xiàn)在不那么流行的老架構(gòu)，而各大項(xiàng)目通常會針對更多的主流用戶和系統(tǒng)，因此這兩者之間總是有矛盾的。從很多地方都可以看出，我們的社區(qū)已經(jīng)被 GCC 所支持的龐大架構(gòu)數(shù)量給寵壞了，但是很多新出現(xiàn)的軟件并不是用 C 語言編寫的，并且還有很多軟件正在從 C 語言遷移到新的語言上去。Rust 語言，就是這些軟件的一個常見選擇。但它是用 LLVM 構(gòu)建的，其支持的架構(gòu)比 GCC 和 Linux 所支持的體系架構(gòu)要少。所以，這里就有一個問題，這些上了年紀(jì)的、不能支持 Rusty 的體系架構(gòu)，對于未開的開發(fā)工作能有多大影響。從好幾個地方看出來，似乎都不會有很大影響。
最新一個問題出現(xiàn)在 Gentoo 開發(fā)郵件列表上。Micha? Górny 指出，Python 加密庫（cryptography library）已經(jīng)開始用 Rust 替換了部分 C 代碼，因此現(xiàn)在要編譯這個庫就需要 Rust。由于 Gentoo Portage 這個 package 管理器會間接依賴于 cryptography library，"因此我們可能會不得不放棄支持那些無法支持 Rust 的架構(gòu)"。他列出了 Rust 所不支持的五個架構(gòu)（alpha、hppa、ia64、m68k 和 s390），另外還有五個架構(gòu)是 Rust 可以支持但是 Gentoo 中還沒有支持 Rust package（mips、32 位 ppc、sparc、s390x 和 riscv）。
Górny 在 cryptography 的 GitHub 倉庫中提交了一個 bug，"但顯然 upstream 認(rèn)為 Rust 的'內(nèi)存安全（memory safety）'比起某些人不能使用這個 package 來說更加重要"。不出所料，library 的開發(fā)者們對事情的看法通常跟發(fā)行版開發(fā)者們會有些不同。但關(guān)于這個 bug 還是有了無數(shù)的評論，這清楚表明許多人對于 2 月 7 日發(fā)布的 cryptography 3.4 版本中的變化感到驚訝。
library 的 contributor 之一 Christian Heimes 明確表示，他們不會取消對 Rust 的依賴。他指出了一個 FAQ 條目，其中介紹了如何禁用 Rust 來構(gòu)建庫的 FAQ 條目，但也指出當(dāng) cryptography 3.5 發(fā)布時，這個方法也不再有效。他還指出，Rust 只是構(gòu)建時需要依賴，在運(yùn)行時就不再需要了。
但在這個 bug report 中，有多人抱怨改為依賴 Rust 這件事并沒有預(yù)先廣而告之。有人認(rèn)為項(xiàng)目遵循的 semantic versioning（版本定義，https://semver.org/ ），就意味著這種變化不應(yīng)該在 minor version 中出現(xiàn)。事實(shí)證明，該項(xiàng)目有自己的版本定義方案，它是允許這種變化的（其實(shí) semantic versioning 也是允許）。但 Heimes 確實(shí)也認(rèn)為之前關(guān)于這個改動的溝通可能還不夠充分。他指出了 2020 年 7 月的一個 PR（pull request）拉動請求和 12 月 22 日 cryptography-dev 郵件列表上的公告，這些都是 Alex Gaynor 發(fā)布的，從而讓這個問題提上了議程。按照這些鏈接找到了很多關(guān)于這個想法的討論，但很明顯，即將進(jìn)行這個改動的計(jì)劃并沒有傳遞到 cryptography 社區(qū)之外。部分原因可能是由于用戶通常拿到 cryptography library 的方式問題，正如 Heimes 所解釋的：
大多數(shù)用戶要么使用 binary wheels (macOS x86_64, glibc Linux x86_64 + aarch64, Windows X86 + X86_64 等平臺上的主要用法)，要么使用 Linux 發(fā)行版中的軟件包。binary wheels 并不需要額外安裝 Rust 庫。只有 Alpine (musl)、BSD、以及其他硬件平臺和發(fā)行版上的用戶受到影響。
許多 Alpine Linux 用戶受到這個改動的影響，其中一些人在評論中大聲地抱怨，他們有持續(xù)集成和部署系統(tǒng)（CI/CD），也會經(jīng)常更新和構(gòu)建相關(guān)的包。不過在這種情況下，因?yàn)?Rust 編譯器缺失，導(dǎo)致其中許多工作都出錯了。不過最新的 Alpine 版本確實(shí)已經(jīng)加上了 Rust 支持，所以這些系統(tǒng)上的修復(fù)可能是很簡單的。
但對于那些目前不支持 Rust，而且事實(shí)上很可能永遠(yuǎn)也不會支持 Rust 的架構(gòu)來說，除了對 cryptography 進(jìn)行 fork 來維護(hù)一個基于 C 預(yù)言的版本之外，沒有其他的辦法了。Górny 在 gentoo-dev 的討論郵件中以及上面提到的這個 bug report 中提出了這個建議。其他人也有類似的想法，但目前還不清楚是否真的有足夠的資源支持這種新的 fork 代碼開發(fā)。Python 3.8 和 3.9 發(fā)行經(jīng)理 ?ukasz Langa 向 Górny (和其他人) 挑戰(zhàn)說，歡迎他繼續(xù)進(jìn)行 fork 工作："我非常歡迎你這么做。請把你的資金和時間按你所說的投入進(jìn)來。一年后我們再看看情況如何。"
Langa 還指出，cryptography 的維護(hù)者也都是志愿者，這意味著他們可以把自己的精力分配到任何他們想做的方向，即使這會讓某些其他志愿者感到麻煩。除此之外，進(jìn)行這個改動是有原因的：
在我開始講之前，我想提醒大家，安全是一個數(shù)字游戲。如果 cryptography 維護(hù)者可以通過改用現(xiàn)代的內(nèi)存安全的語言來幫助 90% 的用戶，如果僅僅因?yàn)槭Ｏ碌?10% 的用戶在用那些無法運(yùn)行 Rust 編譯器的少見平臺而放棄改變，這就是不負(fù)責(zé)任的做法。
[……]你期望那些志愿者讓他們的關(guān)注于安全的項(xiàng)目來繼續(xù)依賴那些本質(zhì)上就不安全的技術(shù)，僅僅因?yàn)檫@會使你自己的工作更容易做。而你的目標(biāo)和要求就不符合 cryptography 庫維護(hù)者的目標(biāo)和計(jì)劃了。對你來說很不幸，但真的就是這么回事。
這個 bug 下面的討論持續(xù)了很多。例如，CI/CD 系統(tǒng)在處理依賴關(guān)系時針對 cryptography 這類庫的版本處理，是有一些問題需要解決的。但也有很多人對于開發(fā)者 "強(qiáng)行" 將自己選擇的 Rust 強(qiáng)加給別人，以及 "破壞" 了許多系統(tǒng)的行為進(jìn)行了抨擊。開發(fā)者們則試圖繼續(xù)幫助那些擁有可以運(yùn)行 Rust 的系統(tǒng)的用戶，而對于其他系統(tǒng)只能聳聳肩表示無能為力了。
最終吵翻了天，然后除了項(xiàng)目貢獻(xiàn)者之外，其他任何人都不允許再發(fā)表評論。而 Gaynor 認(rèn)為這些問題對于這些那些舊平臺來說是不可避免的。關(guān)閉了這個討論后，他總結(jié)了一下討論過的內(nèi)容，并重申 cryptography 開發(fā)者不會因?yàn)槟切┎恢С?Rust 的平臺而改變主意。
回到 Gentoo 這一邊，調(diào)查下來 Portage 之所以依賴 cryptography 是因?yàn)樗褂昧?urllib3 和 requests。Gentoo 中的這兩個軟件包是依賴 cryptography 的，但實(shí)際上并不需要。為了解決這個問題，合并了一個 pull request (https://github.com/gentoo/gentoo/pull/19383)，這樣就避免了對 Gentoo 系統(tǒng)非常重要的 Portage 出現(xiàn)問題。
至少現(xiàn)在是繞過了這個問題。但 Górny 擔(dān)心的是，發(fā)行版的測試中使用的 trustme TLS test-certificate generator 中確實(shí)需要 cryptography，所以有些平臺上可能無法進(jìn)行完整測試。另一方面 cryptography 的開發(fā)者已經(jīng)決定會創(chuàng)建一個 3.3 LTS 版本，在其中維護(hù)引入 Rust 之前的版本，直到 2021 年底為止。不過，在該版本中只會對 CVE 進(jìn)行修復(fù)。
但 Górny 還有一個更大的擔(dān)心。他認(rèn)為，Python 本身未來的某個版本有可能會開始需要 Rust，盡管還不完全清楚他的判斷依據(jù)是什么。這對沒有 Rust 的架構(gòu)上的 Gentoo 平臺來說將是毀滅性的，因?yàn)?Genntoo 發(fā)行版嚴(yán)重依賴 Python。其他發(fā)行版也會有問題，但唯一真正的解決方案是讓 LLVM (因此 Rust 也就能得到支持) 在這些架構(gòu)上能正常工作，或者讓 Rust 的 gccrs GCC front-end (或類似的一些項(xiàng)目) 取得進(jìn)一步的進(jìn)展。
雖然 Python 本身很可能不會完全切換到 Rust 去，但很明顯，Rust 正變得越來越流行。如果它能 "無處不在" 地正常運(yùn)行，那當(dāng)然是最好了，但要達(dá)到這個目標(biāo)還需要一些艱苦的努力。LLVM 的開發(fā)者對支持新的架構(gòu)一直有些戒心，除非他們能確信這個架構(gòu)會在很長時間都會有人支持。這是可以理解的，但卻讓問題變得更加糟糕。
早在 2018 年，我們就在 Debian 和 librsvg 上看到了類似于 Gentoo 的問題，而且我們很可能會看到它在未來幾年內(nèi)反復(fù)出現(xiàn)、頻繁出現(xiàn)。各個項(xiàng)目去使用新的工具，這是很合理的需求，而項(xiàng)目對支持古老架構(gòu)不感興趣也不是沒有道理的。當(dāng)然這是很不幸的，但我們就是總會面臨這些兩難問題。也許，運(yùn)氣好的話，這種困境今后會有所改變。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～