在 Gitian 中使用 Guix 的目的是什麼？這不會重新引入依賴關係和安全問題嗎？
在 Gitian 中使用 Guix 的目的是什麼？這不是重新引入了從 Gitian 過渡到 Guix 的目的的依賴關係和安全問題嗎？
我的理解是 Gitian 是可重現的，但不是可引導的，而 Guix 是對可引導和可重複的改進？
robertspigler 在 IRC 上提出了這個問題。
Gitian 通過使用虛擬機來隔離用於建構的工具鏈來實現可重複性。這意味著任何和所有未經審計和不受信任的第三方二進製文件都在一個封閉的環境中執行，在那裡它們不太可能污染和對主機系統造成損害。
另一方面，Guix 旨在直接在主機本身上執行，因此如果執行了任何未經審計和不受信任的第三方二進製文件，它們可能會對主機造成損害。
因此，一些開發人員，尤其是 luke-jr，希望在虛擬機中執行 Guix 建構，以盡量減少這種風險。這可以通過在虛擬機中安裝 Guix 來實現，但是我們已經有了 Gitian 和它周圍的基礎設施，因此也可以通過在 Gitian 中執行 Guix 來實現這一點，並且不需要這些開發人員弄清楚如何安裝在 VM 中進行 Guix，並維護 VM。
此外，許多參與可重現建構過程的人可能還沒有設置 Guix。通過在 Gitian 內部進行 Guix，這些人將有可能以最小的更改參與新的發布過程。提供一種從 Gitian 過渡到 Guix 的簡單方法是在 Gitian 中啟用 Guix 的主要動機。
當然推薦的方法還是直接使用 Guix 而不是通過 Gitian。在 Gitian 中使用 Guix 會顯著降低性能。此外，直接執行 Guix 可以更容易地調試和解決問題，因為建構器仍然可以使用建構的工具鍊和額外的二進製文件。
fanquake 在 IRC 上回答了這個問題：
將 Guix 用作發布建構環境（或通常用作建構系統）有許多好處。
使用 Gitian，你必須選擇一個 Linux 發行版來建構。這定義了你的工具鏈、可用的包、你建構的 glibc 等等。
這也意味著您受制於上游包維護者的選擇。他們控制更新包版本的方式/時間，應用哪些更新檔，如何編譯等。這有缺點。
例如，我們的安全檢查測試依賴於 mingw-w64 ld 中存在的許多 -no-* 選項。這些選項被修補到 Ubuntu Bionic binutils-mingw-w64 包中的 ld 中，但是，binutils 維護者選擇在 Ubuntu Focal 中停止這樣做，這意味著我們的安全檢查測試將無法執行（他們已經決定在多毛中重新修補它們）。有關詳細資訊，請參閱#18629。
在 Guix 中，因為我們完全控制了我們的工具鏈，所以我們不必擔心這樣的問題，並且可以直接應用我們想要使用的更新檔，這正是我們在 #22381 中所做的，我們開始將 -no-* 連結器選項修補到我們的 mingw-w64 工具鏈中。我們可能依賴的編譯器/連結器選項或預設值不能再從我們下面隨機更改。
對此，有些人可能會說“只要不更改 Ubuntu 基礎映像，事情就不會改變”。對此，我想說，我不希望項目處於我們“卡住”的位置，並且無法更新我們的基礎映像以使用新工具（即編譯器），因為這樣做我們’只會破壞其他東西，比如我們的安全測試。
通過建構和使用我們想要的發布建構環境來完全消除這些問題的可能性似乎更聰明。
“好吧，為什麼不只是在 gitian 中打更新檔/更改內容” - 我不會對此多說，除了，gitian 環境根本沒有設置來執行我們可以在 Guix 中輕鬆實現的相同類型的更新檔。例如，嘗試修補和編譯 gitian 描述符中的 mingw-w64 工具鏈也會變得一團糟。
同樣的道理也適用於 gitian 使用與該版本 Ubuntu 上已有的不同的 glibc 建構任何東西。
這具有向後兼容性的含義，因為您正在建構的 glibc 版本基本上決定了您的執行時 glibc 兼容性。然而，這可以通過使用我們目前在 glibc-back-compat 程式碼中擁有的各種“解決方法”來擴展。
現在，類似於您可能想要使用較新的 Ubuntu 版本（出於多種原因）的情況，這樣做意味著您必須針對較新的 glibc 進行建構（您只需獲得該 Ubuntu 版本附帶的任何版本） .
這意味著當你使用更新版本的 glibc 時，你需要保持向後兼容性的“變通辦法”的數量會越來越多，變得越來越複雜，甚至開始洩漏比特幣核心程式碼，進入我們的依賴系統。查看此評論中連結的所有 PR： https ://github.com/bitcoin/bitcoin/pull/22418#issuecomment-876379846 。
像這種洩漏到依賴項中的更改是不好的，因為現在使用依賴項的普通建構器現在受到更新檔的副作用的影響，這些更新檔只在我們的發布建構環境中真正需要。也許您會爭辯說，在這種情況下，我們應該只在建構發佈時應用依賴更新檔，但是您會遇到發布建構與“正常”/開發人員建構更加不同的情況，這意味著要麼保持均勻更複雜的 CI / 測試常式，或者它們最終測試較少（猜猜哪一個更有可能發生）。
如果這一切聽起來像是一團糟，那基本上是因為它是。然而，使用 Guix 的解決方案實際上非常簡單。
當我們完全控制我們的發布環境時，我們可以準確地選擇我們想要使用的 glibc 版本（即使在每個主機級別），這是我們絕對無法以任何直接的方式實現的，如果有的話，使用 gitian。
這是我們最近在#22365 中所做的事情。我們現在使用 glibc 2.27 建構 RISC-V HOST，並使用 glibc 2.24 建構所有其他的，同時保持與 glibc 2.17 的執行時兼容性。您會注意到，無需使用我們的 glibc-back-compat 程式碼 (#22405) 中的任何變通方法或上述評論中提到的任何其他 PR / 更改即可實現這一點。
這些只是使用 Guix 提供的兩個非常實際的好處（還有更多），最終歸結為我們可以更好地控制我們的發布建構環境。我非常高興的事情，我認為對於像比特幣核心這樣的項目很有意義。
Guix 領域也有很多人在積極致力於可引導性的工作這一事實只是另一個很大的好處，即使這並不像現在有些人想要的那樣工作，但它正在迅速得到改進，月復一月。
Guix 也是 gitian 可以提供的完全可引導的比特幣核心建構的更有可能的途徑。
dongcarl stated:
我不認為我們會在 Gitian 中執行 Guix 來發布版本，但我個人認為人們可以自由地做任何他們認為有意義的事情，只要他們致力於維護它
盧克-JR補充說：
在 gitian 中執行它不會失去那些 Guix 的好處；gitian 只是提供了避免安全性倒退所需的隔離