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

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

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

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

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

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

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

正方：Nix社區(qū)說"這是用戶誤用"

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

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

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

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

Selldorff在回應(yīng)Dolstra時甩了一組數(shù)據(jù)：那47%的幽靈依賴?yán)铮?1%發(fā)生在官方推薦的`mkDerivation`模板內(nèi)，而非開發(fā)者自定義腳本。換句話說，最標(biāo)準(zhǔn)的寫法照樣漏。

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

「這不是用戶剪安全帶，是安全帶本身有個出廠沒修的洞?！顾诩夹g(shù)博客寫道。

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

Manifest的掃描邏輯，到底準(zhǔn)不準(zhǔn)

爭論的核心是"干凈"的定義權(quán)。Nix社區(qū)說"聲明文件+鎖文件=干凈"，Selldorff說"實際構(gòu)建行為與聲明一致=干凈"。兩種標(biāo)準(zhǔn)差了一個觀測層。

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

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

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

工程師該站哪邊

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

Nix的"純函數(shù)式部署"是個數(shù)學(xué)概念，針對的是構(gòu)建系統(tǒng)的內(nèi)部一致性。你給它相同的輸入，它保證相同的輸出——這個承諾在Nix Store的邊界內(nèi)是成立的。但輸入本身的完整性，Nix并不擔(dān)保，它假設(shè)你提供的源代碼和URL是誠實的。

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

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

兩者都在進(jìn)化，只是節(jié)奏不同。工程師的務(wù)實選擇是：繼續(xù)用Nix，但把Selldorff的掃描邏輯塞進(jìn)發(fā)布流程。干凈不是聲明出來的，是測出來的。

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