RFC-0119:系統判定為有害的路徑系統

RFC-0119:系統視為有害的系統絕對路徑
狀態已接受
領域
  • 建構
說明

制定政策以盡可能使用任何位置的相對路徑。

問題
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-06-20
審查日期 (年-月-日)2021-07-28

摘要

  1. 制定政策時,優先使用相對路徑或來源絕對路徑,而非 著眼於多個列舉例項中的系統絕對路徑 用途
  2. 改以自動化方式強制執行這項政策,建立迴歸 停靠站。
  3. 清除既有的系統絕對路徑用法。

背景

熟悉該主題的讀者可能會想跳過

路徑

定義

讀者應熟悉 paths

我們使用下列定義:

  • 系統絕對路徑:根層級本機檔案系統的路徑。通常以 / 前置字串。
  • 來源絕對或專案絕對路徑:與 原始碼樹狀結構或專案結帳通常以 // 前置字元表示。
  • CWD 相對路徑:相對於目前工作目錄的路徑。

下文將以系統絕對路徑做為絕對路徑進行一般化 相對路徑,以相對路徑表示,因為以 另一個路徑

Fuchsia 建構系統中的路徑

路徑用於建構系統,用來參照動作的輸入和輸出檔案。 Fuchsia 建構系統使用 GN 來定義 圖表。建議您先參考公認最佳做法 表示 GN 中的路徑與其他根目錄的相對路徑,例如 根建構目錄或來源根目錄。

產生的程式碼中的路徑

程式碼可能會基於各種原因參照路徑。已檢查的原始碼 無法參照絕對路徑,因為這類路徑無法可攜式 修訂佇列 (CQ) 機器上的意義並予以拒絕, 他們確實採取了相同的絕對路徑,對其他工程師的任務毫無意義 能使用相同的流量不過 而未登記這些程式的 可能包括絕對路徑 應用程式 (即建構和/或執行) 所需的資源。

Fuchsia 使用許多工具來產生原始碼,例如 FIDLfidlc」和 Banjo 使用類似的工具。

提振精神

基於幾個原因,最好將相對路徑和 建構系統、工具叫用、產生原始碼等 導致學習失真性

可攜式構件

如上所述,相對路徑可以移動,因為相對路徑是 供雙方達成共識的參考點, 原始碼結帳或建構輸出目錄的根層級。在許多情況下 比起可攜性,

分散式版本的可攜式構件

發布建構動作是將輸入內容傳送至建構動作 例如將 C/C++ 檔案編譯為物件檔案 遠端伺服器得代表用戶端執行動作, 系統會傳回結果。遠端伺服器通常會使用以內容為基礎的 快取即可完全略過動作。

發布建構動作有許多好處,不在這個範圍內 文件。

用戶端和伺服器可能不同意絕對路徑,相對路徑 可能需要指定要發布的叫用詳細資料,以便分配為 並寫入所有上傳的構件內容中,彼此之間相互參照。 這對仰賴快取的分散式建構系統來說尤其重要。 叫用詳細資料做為快取金鑰的一部分。即使 允許使用絕對路徑,因此其用途可能會破壞快取機制,因為 用戶端可查看相同的原始碼,然後將請求傳送至 提供與絕對路徑不同的結果

建構路徑或產生的程式碼中存在絕對路徑,導致 無法解決先前發布的版本問題例如 Fuchsia 開發人員 Goma 用於發布 C/C++ 建構動作。的 Fuchsia 使用者 Goma 在採用絕對變更前曾發生服務中斷的情況 C/C++ 的路徑包含目錄在部分執行個體中分散式建構作業 會失敗並強制執行本機回退,速度較慢。在其他情況下 分散式版本會成功,但無法快取,導致 導致連鎖性故障。

發布建構動作時,另一個類似的失敗模式是絕對路徑 工具叫用中的圖片。我們先前發現這項功能非常實用 發布動作前請先檢查是否有這類路徑,並在表單中拒絕 並顯示有用的錯誤

在「其他執行個體」絕對路徑中,導致建構正確性 以負載平衡機制分配流量 即可降低應用程式發生效能問題的風險

管道用的可攜式構件

發布動作時,有時候會需要一個遠端的管道 以處理不同任務舉例來說,某些機器比較適合 和其他更適合執行建構的測試 有時候,動作會以分支和彙整的圖表表示,例如 建構一系列的測試,然後對多部機器執行 資料分割,然後彙整結果。

在先前案例中的路徑,是用戶端與伺服器交換 在這個案例中,路徑會在管道中的不同伺服器交換。 相對路徑,相對路徑和 原因也都一樣

絕對路徑可能會導致管道中斷。舉例來說 的測試涵蓋範圍過去曾發生故障 在較早階段產生的報表,包含了 無法在執行其他伺服器後解析原始碼 涵蓋率報表製作管道的階段多數情況下 涵蓋範圍對應檔案使用絕對路徑,我們變更了 來取得指向指定基底的路徑。

使用其他形式的程式碼時,也發生類似的故障 檢測 - 偵錯資訊檔案中,曾經使用絕對路徑, 記錄,用來解析原始碼行的相對電腦偏移。

用於快取的可攜式構件

系統可能會快取建構作業輸出內容,以便加快後續建構速度,稱為 漸進式建構作業這類快取通常會儲存在本機,例如 或是建構伺服器的特定執行個體理論版本 不同的建構工作站 (工作站 但沒有網路容量可以負擔 無安全機制和隱私權疑慮。

目前 Fuchsia 不會重複使用不同機器之間的建構快取,因為 已知部分建構輸出內容包含絕對構件。反之,Fchsia 開發人員和分散在各地的建構工具 擷取快取資料這嚴重損失 有機會進行最佳化並提高工程生產力。

可重現的構件

在構件中使用絕對路徑會導致無法重現 版本

目前對於 Fuchsia 而言,可重現的建構並不是目標。但 有趣的是,要考慮可重現版本的優點 但瞭解這可能是日後需要的資源 無法重現成果

另請注意,還有其他無法重現的成果來源,大多數 範圍之外的時間戳記,所以不在 RFC 的範圍內。

最少的工作

Fuchsia 目前為了在裝置上執行測試 製作了完整的系統映像檔 儲存裝置。我們希望未來能加快這項程序,例如: 就像推送至測試裝置一樣,上傳自上次 更新時間。預計大部分的測試變更只會影響 與基本變更相對的少量 blob,因此這種作業方法 會大幅縮短測試裝置的時間

如果絕對路徑外洩到構件,可能會使更多 blob 失效 並測試不需要的變動。

Fuchsia 的非主流建設

上面我們說明 Fuchsia 因絕對值 以及絕對路徑中的絕對路徑 不斷推陳出新想要以絕對路徑解決問題,急需達成以下目標: 而是根據歷史背景資料建立而成例如,過去 Fuchsia 並沒有 利用漸進式建構作業或快取,使專案和人員 學習到可容許的缺陷,讓 Fuchsia 無法 提供更多漸進式建構作業和快取

如果 Fuchsia 成功,其他專案就會使用程式碼和構件 開發出 Fuchsia 的成功案例。可以放心假設 因此,這些專案具有建構規則與工具的系統 來滿足 Fuchsia 專案的需求舉例來說 客戶的營運規模可能包括漸進式版本, 是不可或缺的因此 快取。Fuchsia 提供阻礙 這些資源讓 Fuchsia 開發人員和其他客戶面臨障礙 才能採用負責任的 AI 技術

分散式信任

如果版本的所有構件都可以重現,這就開啟了新的大門: 建構系統的屬性例如可重現的執行個體 版本可做為分散式替代方案 用來驗證分散式完整性的加密編譯鏈 二進位檔。不受信任的方只需嘗試 使用相同的來源和建構系統重製執行個體。無法重現 二進位檔可能是遭到惡意竄改的證據。

若構件中使用絕對路徑,就不會有信賴的一方 可重現相同的結果

便利性

相對路徑在疑難排解時更容易使用。一般而言 因此可以針對一致性的預期 作業失敗,並判定任何有意義的作業 差異在於

嚴格在本機工作時,絕對路徑會非常方便。適用對象 使用者可從工具叫用複製絕對路徑,並用於 不同的本機殼層環境,保證可以運作 與目前工作目錄相對應的執行個體此外,任何兩個路徑 絕對值和正規化的 (例如 ... 部分均已解析) 連結等) 可用字串識別是否相等。 由於任何路徑都可以設為絕對和正規化 轉換是等冪的,這個物件提供 對路徑進行簡易對等檢查 可以連線至本機環境不過,並沒有什麼條件會限制使用者 如果覺得更方便的話 對絕對路徑執行這項轉換 但因為這是相對於絕對和/或正規化形式的轉換作業 無法朝向另一個方向運作因此 更多元包容,更偏好使用相對形式。

設計

政策

我們會採用已記錄的 GN 最佳做法, 一般政策,而且會比只套用到 BUILD.gn 檔案更廣泛地套用政策。 具體來說,我們會建議您採取下列做法:

  1. 由建構系統以指令列引數形式傳遞至工具的路徑 應與目前叫用工具的工作目錄相對 (如果是 GN/Ninja,則以 root_build_dir 表示)。
  2. 建構時產生的檔案路徑應與相同的根層級 建構目錄例如:產生的原始碼、套件資訊清單 depfiles.
  3. 在執行階段產生的路徑應與專案來源相關 根目錄。例如:當機檔案中的檔案資訊、測試涵蓋範圍報告。

違規處置

我們將導入新工具,針對 Fuchsia 版本進行掃毒,以防止危害 工具叫用和構件中的絕對路徑這些工具會是 在 CQ 內練習來避免迴歸

清除

上述工具具有預設用途的許可清單, 初始化列出政策的所有現有違規事項。清除所用資源 將許可清單大小降至零。迴歸無法 列入許可清單。

實作

違規處置工具的運作方式並未增加 符合 RFC 規範不過,我們稍後會列舉一些構想,供你參考 進而瞭解自己的讀者

清理 Ninja 檔案

執行 GN 會產生說明建構圖表的 build.ninja 檔案。 這張圖表的說明包含所有工具叫用,包括 並傳遞至這些工具做為引數的路徑 所使用的其他檔案會在 depfile 中參照。

可以使用 strings 處理這些檔案,並產生 系統會篩選這類物件這個簡單的掃描器可能以 舉例來說,做為主機測試,可依據所有建構作業 子類

清理建構參照的檔案

除了清理 Ninja 檔案外,我們還可標記及清理任何 指定為建構動作的輸入或輸出內容檔案。我們將能 探索 Ninja 圖或 depfile 中的所有這類檔案 (假設 是 hermetic

檢查是否存在絕對路徑的字串

我們可以掃描建構輸出目錄 (out/) 下的所有檔案,然後產生 字串,檢查其中是否有任何絕對路徑,然後發出錯誤。這不是 所謂萬無一失的防護,只是提供另一道簡易的防線。

在動作追蹤器中拒絕絕對路徑

我們已有納入 GN 動作的工具, 用於拒絕 depfile 中的絕對路徑。我們可以擴大此範圍 以進一步擴大

請注意,我們目前只會使用動作追蹤器納入自訂動作; 也就是所有建構動作的子集手動操作 費用問題從這個角度來看 後續追蹤的動作追蹤並不是完善的全方位策略

撤銷絕對路徑

讓結帳中的所有相對路徑保持運作的簡單方法 而完全失效的絕對路徑是產生 Ninja,然後 請將結帳目錄移至其他位置 (或重新命名),然後建立結帳目錄。

$ fx gen
$ mv $FUCHSIA_DIR ${FUCHSIA_DIR}_renamed
$ fx build

如果結帳頁面中的任何建構叫用參照路徑是絕對值,則 建構失敗

這個做法非常容易實作、可攜性,而且效能不足 同時免除不必要的負擔有些缺點包括在發生故障時產生的錯誤訊息 這種錯誤可能導致您無法理解, 而 所產生構件中的絕對路徑 (例如執行個體 depfiles、srcgen、偵錯等 資訊)。

執行階段環境的變更

另一個做法是變更建構作業的執行階段環境 絕對路徑 (以無效方式轉譯或轉譯為無害)適用對象 「部分專案」運用了各種概念, chroot 會在結帳根層級形成沙箱。其他 建構系統使用特殊的 才能採用沙箱機制

執行階段方法可以帶來更高的正確性,因此值得考慮 保證。但具有效能 疑慮 可攜性 問題

安全性考量

路徑可用於解釋路徑 (也就是 實際解析的檔案) 可能會影響敏感的系統行為。適用對象 例如可對應至記憶體執行檔的許可清單 網頁。

在這種情況下,使用專案相對路徑會比使用執行個體路徑更好 是相對於指定清單的目錄 或與處理此清單的工具 CWD 相對的路徑這個 是因為專案相對路徑的解析方式並不明確 但其他形式的相對路徑 會以全域可變動狀態 (例如 CWD) 以不同方式解讀。

隱私權注意事項

絕對路徑有時會洩漏個人識別資訊。適用對象 每個人的使用者名稱通常都會出現在絕對路徑中 或建構輸出目錄中的檔案。取代中 包含來源相關路徑的絕對路徑能避免這個位置出現 PII。

測試

先前我們探討了幾種能擷取絕對使用值的檢查方法 路徑。這些檢查是以建構步驟或主機測試的形式實作,因此 能在 CQ 中運作,並做為持續測試

想要確保絕對路徑不會使用絕對路徑,另一種方式是 不會歸咎於工程工作流程的重要面向舉例來說, 絕對路徑會破壞已分散式的特定動作 ,開發人員無法再導入服務中斷情形。

說明文件

如果強制執行該路徑的工具沒有絕對失敗,它們應該 錯誤訊息,連至適當的疑難排解網頁。做為靈感 動作追蹤程式,會強制系統將建構動作 密封失敗會產生錯誤訊息,並提供密封建物的連結 動作頁面。

缺點、替代方案和未知

但在分散式建構空間中失去商機時,我們不必採取任何行動。 可重現性的工作

我們可以強制執行政策,但無法強制執行。可能的後果 無法在發行版本上或 實際做法。

我們可以解決這個問題,但會額外承擔,如果超過 時間也跟宇宙衰退的本質有關

既有藝術品和參考資料

偉大的絕地武士說:「只有西斯門優惠入底。」