Nix部署被吹了3年干凈，Manifest工程師翻出47%的隱藏

「你的Nix部署看起來很干凈，但很可能不是。」Alexandra Selldorff在Manifest的SBOM掃描日志里敲下這句話時，手里正攥著一份讓團隊沉默的報告：那些號稱"可復現、無依賴地獄"的Nix環境，47%藏著聲明文件里沒寫的幽靈依賴。

作為Manifest的工程負責人，她每天的工作是給軟件供應鏈拍X光。NixOS社區吹了十幾年的"純函數式部署"，在她眼里像個精心打掃過的房間——表面一塵不染，掀開地毯全是灰塵。這不是技術信仰崩塌，是審計工具終于跟上了營銷話術。

Nix的干凈承諾，卡在哪一步

Nix的核心賣點很簡單：用聲明式配置（聲明式配置，即通過代碼描述系統終態而非安裝步驟）鎖定整個依賴樹，同一套配置在任何機器上構建出比特級一致的環境。理論上，你從Git倉庫拉取`flake.nix`，就能復現一臺2021年的生產服務器。

問題是"聲明"和"實際"之間有條縫。

Selldorff的團隊掃描了127個公開Nix項目，發現近半數在構建時拉取了未在鎖文件中顯式聲明的資源。有些是構建腳本里硬編碼的curl下載，有些是插件系統自動抓取的最新版工具鏈，還有些是開發者本地緩存的"臨時補丁"忘了提交。

這些幽靈依賴不會破壞日常運行。Nix的構建緩存機制（Nix Store的哈希尋址）甚至能正常復現它們——只要原始URL還能訪問。但一旦上游倉庫下線、版本被覆蓋，或者安全補丁發布，你的"可復現構建"就變成了薛定諤的盒子：今天能跑，明天可能哈希對不上，卻沒人知道少了什么。

正方：Nix社區說"這是用戶誤用"

NixOS基金會的技術委員會成員Eelco Dolstra（Nix原始作者）在郵件列表回應過類似質疑。他的論點很直接：Nix提供了純函數式的構建沙盒，但開發者可以選擇不用。那些繞過`fetchurl`校驗、在`buildPhase`里偷偷wget的行為，相當于把安全帶剪了再抱怨車禍。

社區的主流聲音支持這一立場。2023年NixCon的調研顯示，82%的"構建不可復現"案例源于開發者使用了`impureEnvVars`（非純環境變量）或自定義構建腳本。官方文檔明確警告過這些逃逸艙口，只是大多數人沒讀。

更激進的辯護者認為，Selldorff的掃描方法論本身有偏。Manifest的SBOM工具基于運行時依賴分析，而Nix的設計哲學是"構建時確定性優先"。兩者的時間窗口不同：構建時干凈的環境，運行時可能動態加載額外庫；反過來，構建時的幽靈依賴如果從未被實際鏈接，對運行時安全就是噪音。

反方：工具沒攔住人，就是工具的鍋

Selldorff在回應Dolstra時甩了一組數據：那47%的幽靈依賴里，61%發生在官方推薦的`mkDerivation`模板內，而非開發者自定義腳本。換句話說，最標準的寫法照樣漏。

她舉了個具體案例。某流行的Nix Python環境管理工具，在`shell.nix`里封裝了`poetry2nix`（Poetry依賴的Nix封裝器）。這個封裝器為了加速構建，默認啟用了`preferWheels`——從PyPI直接拉取預編譯wheel，而非從源碼構建。wheel的內容不會進入Nix Store的哈希校驗，相當于在純函數式城堡底下挖了條地道。

「這不是用戶剪安全帶，是安全帶本身有個出廠沒修的洞。」她在技術博客寫道。

更深層的問題在于Nix的生態系統激勵。Nixpkgs（官方軟件包倉庫）有超過8萬個包，維護者不可能逐行審計每個構建腳本。而"能跑就行"的PR文化，讓大量包裹層（wrapper）代碼以"臨時方案"的名義進倉，一待就是五年。

Manifest的掃描邏輯，到底準不準

爭論的核心是"干凈"的定義權。Nix社區說"聲明文件+鎖文件=干凈"，Selldorff說"實際構建行為與聲明一致=干凈"。兩種標準差了一個觀測層。

Manifest的SBOM工具采用動態追蹤：在沙盒里運行完整構建流程，抓取所有網絡請求和文件系統操作，再與靜態聲明比對。這種方法能發現`flake.lock`沒記錄的`curl | bash`，但也會把正常的構建時工具（比如編譯器本身）標記為"潛在幽靈"。

Selldorff承認有假陽性。她的團隊手動復核了掃描結果，剔除了Nix Store內置工具鏈的干擾后，硬性的"聲明外依賴"仍占31%。這些不是誤報，是實實在在的哈希逃逸。

一個典型場景是Git子模塊。Nix的`fetchGit`支持遞歸拉取子模塊，但子模塊的鎖文件不會被納入主倉庫的`flake.lock`哈希計算。如果子模塊維護者強制推送了重寫歷史，你的構建哈希不變，內容已經變了——而Nix的"純函數"承諾對此毫無感知。

工程師該站哪邊

我的判斷是：雙方都在說真話，但說的不是同一件事。

Nix的"純函數式部署"是個數學概念，針對的是構建系統的內部一致性。你給它相同的輸入，它保證相同的輸出——這個承諾在Nix Store的邊界內是成立的。但輸入本身的完整性，Nix并不擔保，它假設你提供的源代碼和URL是誠實的。

Selldorff的掃描針對的是工程現實：人不會永遠誠實，工具不會永遠被正確使用。當她發現47%的項目有幽靈依賴時，她不是在否定Nix的設計，是在指出"設計"到"落地"的衰減曲線。

對25-40歲的技術從業者來說，關鍵問題不是"Nix好不好"，而是"我的審計工具能不能覆蓋Nix的逃逸艙口"。Manifest開源了他們的SBOM掃描器（基于BuildKit的細粒度追蹤），但集成到CI需要改流水線。Nix社區也在推進`contentAddressedDerivations`（內容尋址推導），試圖把運行時實際內容納入哈希校驗——這能解決部分問題，但增加了構建緩存的失效頻率。

兩者都在進化，只是節奏不同。工程師的務實選擇是：繼續用Nix，但把Selldorff的掃描邏輯塞進發布流程。干凈不是聲明出來的，是測出來的。

Manifest的掃描報告最后附了條腳注：那47%的項目里，有12個在收到披露后三周內修復了幽靈依賴，方式是給`buildPhase`加了`disallowedRequisites`（禁止依賴項）限制。剩下的35個，維護者回復"不影響功能，暫不處理"。