| RFC-0133：軟體交付目標 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 軟體交付領域的一組長期目標。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-09-08 |
| 審查日期 (年-月-日) | 2021-10-04 |
摘要
軟體交付領域的一組長期目標。
提振精神
Fuchsia 軟體發布系統需要優先處理客戶需求，未來也會繼續這麼做，但我們也需要設定長期方向，以便在設計時謹記在心。雖然我們對許多目標沒有明確的客戶需求，但這些目標仍是我們在演進系統時應設計和牢記的目標。這份清單可能會隨時變動，這很正常。不過，這代表了當今世界所期望的狀態。
利害關係人
協助人員：
hjfreyer@google.com
審查者：
- abarth@google.com - FEC
- amathes@google.com - Product
- computerdruid@google.com - SWD
- ampearce@google.com - Security
已諮詢：
- kitlane@google.com
- mckillop@google.com
- hjfreyer@google.com
- 軟體交付團隊
社交：
這項 RFC 已由軟體交付團隊和貢獻者以文件形式審查。
設計
目標
- 優先考量客戶需求：如有迫切的客戶需求，只要不影響長期目標，我們應勇於重新檢視現有導入項目或變更策略。
- OTA
- 平台和非平台更新具有相同功能：平台 OTA 和獨立模組的更新具有相同功能 (管道、分階段推出、跳板等)，OSS 使用者應可使用這些功能。
- 減少單體式架構：我們希望平台的大部分元件都能獨立更新。
- 提供可修改持續性狀態的攻擊復原選項： SWD 堆疊應能在開機時自動執行更新，並盡量減少對可變動資料和其他軟體的依附性，以盡可能從嚴重安全漏洞 (包括可讓攻擊者修改持續性狀態的漏洞) 中復原。
- 更新可靠性至關重要：只要能證明更新軟體不會影響安全性需求，我們就應優先更新軟體。我們應優先考慮簡單可靠的程式碼，即使會對效能造成合理影響也無妨；我們的目標是建立最簡單的系統，能夠正確且安全地執行更新，並符合其他效能需求。我們應偏向安全失敗的設計，並允許再次更新，而不是可能在另一次嘗試中損毀狀態。
- 產品擁有者決定其產品的策略 ：平台定義了哪些軟體更新策略可以表達，並建議初始策略。產品擁有者可以選擇政策設定，並隨時變更政策選項，即使裝置已部署完畢也沒問題。
- 所有軟體都會根據預設政策進行驗證：所有軟體都會根據為該類型軟體定義的政策進行檢查。這些政策可能包括可執行程式碼的出處檢查、完整性檢查、沙箱等。如果沒有預先定義的政策機制，任何軟體都無法執行。
- 軟體來源政策是產品相關問題
- 平台不會限制軟體發布者，也不會規定需要哪些核准。集中式與去中心化軟體來源是產品政策，而非平台政策。只要軟體發布時附上適當的中繼資料 (例如發布者簽章)，平台就應該能夠執行。
- 平台會建立機制來強制執行軟體政策，但產品擁有者可自行決定可用的軟體來源。產品擁有者可以透過政策限制可用的軟體來源，但平台不會這麼做。
- 平台應能產生可安裝任意軟體的產品，包括允許使用者在裝置上執行任意發布者軟體的功能。
實作
我們會在軟體推送說明文件中加入這項 RFC 的連結，並在軟體推送領域的設計流程中謹記這項 RFC。
效能
不會影響效能。
安全性考量
這項 RFC 的實作不會立即影響安全性。從長遠來看，我們預期在執行這些目標時，會與安全團隊進行大量協作，因為 SWD 更新機制是我們在現場保護漏洞的主要方法。
隱私權注意事項
這項 RFC 的實作不會影響隱私權。從長遠來看，我們預期在達成這些目標的過程中，會與隱私權團隊進行大量合作。
測試
這項 RFC 的實作不會影響測試。
說明文件
我們會從軟體推送 README 連結至這個 RFC。
缺點、替代方案和未知事項
我們可以為軟體交付領域設定的目標幾乎無上限。 我們認為這些目標最能準確呈現堆疊的現狀和期望狀態。
我們仍有許多未知數，例如如何與任何可能的第三方軟體發布商整合。一旦我們掌握客戶對可能功能的具體需求，就能更妥善地處理這些未知情況。
既有技術和參考資料
先前發布的 SWD 藍圖資訊非常少。不過，許多先前的套件管理和軟體供應鏈安全疊代版本都存在。以下列舉一些先前技術：