| RFC-0133：軟體提交目標 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 軟體提交區的一系列長期目標。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-09-08 |
| 審查日期 (年-月-日) | 2021-10-04 |
摘要
軟體提交區的一系列長期目標。
提振精神
Fuchsia 軟體提交系統必須優先考量客戶的需求，並將持續這麼做，但我們也需要設定長期方向，在設計時時刻記在心。雖然我們沒有針對許多目標明確的客戶需求，但這些目標仍是我們在設計和改進系統時應考量及考量的目標。這份清單可能會隨時間變更，這沒關係。不過，這代表了現今世界所需的狀態。
利害關係人
協助人員：
hjfreyer@google.com
審查者：
- abarth@google.com - FEC
- amathes@google.com - 產品
- computerdruid@google.com - SWD
- ampearce@google.com - 安全性
諮詢：
- kitlane@google.com
- mckillop@google.com
- hjfreyer@google.com
- 軟體推送團隊
社會化：
這項 RFC 已透過文件形式，由軟體提交團隊和貢獻者進行審查。
設計
目標
- 優先考量客戶需求：只要不影響長期目標，我們不應害怕重新檢視現有導入作業或變更策略，以滿足客戶迫切的需求。
- 正式版的更新通訊協定：正式版的所有裝置都會使用相同的更新堆疊和平台通訊協定 OTA
- 平台和非平台更新具有相同的功能：平台 OTA 和獨立模組的更新具有相同的功能 (管道、分階段推出、踏腳石等)，OSS 使用者應可使用這些功能。
- 盡量減少單體：隨著時間推移，我們希望平台的大部分部分都能獨立更新。
- 針對可修改持續性狀態的攻擊提供復原選項：SWD 堆疊應能在啟動時自動執行更新，並盡可能減少對可變動資料和其他軟體的依賴，以便盡可能復原嚴重漏洞，包括讓攻擊者修改持續性狀態的漏洞。
- 更新可靠性至關重要：只要我們能證明軟體更新不會影響安全性規定，我們就會優先更新軟體。我們應優先採用簡單可靠的程式碼，即使這會對效能造成合理影響也一樣。我們的目標是建立最簡單的系統，以便正確安全地執行更新，並滿足其他效能需求。我們應偏向設計安全失敗的情況，並允許更新的另一個機會，而不是可能會損壞狀態的另一個嘗試。
- 產品擁有者可以選擇政策設定，並隨時變更政策選項，即使裝置已在現場使用也一樣。
- 所有軟體都會根據特定政策進行驗證：所有軟體都會根據針對該類型軟體定義的政策進行檢查。這些政策可能包括可執行程式碼的來源檢查、完整性檢查、沙箱等。如果沒有預先定義的政策規則，就無法執行任何軟體。
- 軟體來源政策是產品問題
- 平台不會限制誰可以發布軟體，也不會要求取得哪些核准。集中式與去中心化軟體來源是產品政策，而非平台政策。只要軟體是以適當的中繼資料 (例如發布者簽名) 發布，平台就應該能夠執行該軟體。
- 平台會建立機制來強制執行軟體政策，但產品擁有者可決定可用的軟體來源。產品擁有者可以透過政策限制可用的軟體來源，但平台不會。
- 平台應具備產生可安裝任意軟體的產品能力，包括讓使用者允許任意發布者在裝置上執行軟體的功能。
實作
我們會在軟體提交的說明文件中提供此 RFC 的連結，並在軟體提交區的設計程序中納入這項資訊。
成效
不會影響效能。
安全性考量
實作這項 RFC 不會對安全性造成立即影響。長期來說，我們希望在執行這些目標時，能與安全性團隊進行密切合作，因為 SWD 更新機制是我們在實務上防範漏洞的主要方法。
隱私權注意事項
實作這項 RFC 不會影響隱私權。長期來說，我們希望在執行這些目標時，能與隱私權團隊密切合作。
測試
實作這項 RFC 不會影響測試。
說明文件
我們會在軟體提交 README 中連結至這份 RFC。
缺點、替代方案和未知因素
我們可以為 Software Delivery 區域設定幾乎無限的目標。這些目標最能代表堆疊的目前狀態和我們期望的狀態。
我們面臨許多未知因素，例如如何與任何可能的第三方軟體發布商整合。一旦我們掌握客戶對可能功能的需求，就能更妥善地推斷這些未知項目。
既有技術與參考資料
先前發布的 SWD 路線圖資訊非常少。不過，許多先前的套件管理和軟體供應鏈安全性版本都存在問題。以下是選錄的先前技術：