| RFC-0133：軟體推送目標 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 是軟體推送領域的長期目標。 |
| 更小鳥 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年月分) | 2021-09-08 |
| 審查日期 (年-月-日) | 2021-10-04 |
摘要
是軟體推送領域的長期目標。
提振精神
Fuchsia Software Delivery 系統必須以客戶需求為優先考量，並會持續這麼做，但我們也在設計時必須謹記長期方向。雖然我們對許多這些目標並沒有明確的客戶要求，但仍在設計系統的過程中，應謹記這些目標並謹記在心。這份清單可能會隨時間變動，沒有關係。不過，這代表目前世界的所需狀態
相關人員
講師：
hjfreyer@google.com
審查者：
- abarth@google.com - 美國聯邦選舉委員會
- amathes@google.com - 產品
- PCdruid@google.com - SWD
- ampearce@google.com - 安全性
諮詢時間：
- kitlane@google.com
- mckillop@google.com
- hjfreyer@google.com
- 軟體推送團隊
社會化：
這個 RFC 已通過與軟體推送團隊的審查文件形式，和貢獻者共同進行了審查。
設計
目標
- 優先考量客戶要求：如果我們有說服的客戶需求，只要 Google 沒有推定長期目標，我們就不會恐怕會重新審視現有的實作方式，或是調整策略。
- 平台和非平台更新有相同的功能：獨立模組的平台 OTA 和更新擁有相同的功能 (管道、階段推出、逐步更新等)，且 OSS 使用者應該可以使用這些功能。
- 盡量減少單體式：長期下來，我們期望平台的大部分部分都能獨立更新。
- 針對可以修改永久狀態的攻擊提供復原選項：SWD 堆疊應能在啟動時自動執行更新，且最少需依賴可變動的資料和其他軟體，才能最大程度地將嚴重安全漏洞的復原風險降到最低，包括讓攻擊者能修改永久狀態的功能。
- 更新可靠性是首要之務：在證明軟體不會違反安全性規定的情況下，我們會建議您更新軟體。即使程式碼仍能維持合理效能，我們仍應優先採用簡單可靠的程式碼；此外，我們的目標是打造最簡單、能夠正確執行更新，且符合其他效能需求的系統。我們不應偏愛設計未嚴重的更新，並允許另一次更新，而不會因為再次嘗試而毀損狀態。
- 產品擁有者可以選擇政策設定，且隨時都可以變更政策選擇，即使裝置已開始進行。
- 所有軟體都會依據蓄意政策進行驗證：所有軟體都會根據針對該軟體類型定義的政策執行檢查。這些政策可包括針對可執行的程式碼、完整性檢查、沙箱等來源執行來源檢查。如果沒有預先定義的政策架構，所有軟體就無法執行。
- 軟體來源政策是產品考量
- 平台不會限制可發布軟體的人員，也不會限制必須獲得核准。集中化與分散式軟體來源屬於產品政策 而非平台政策只要軟體以發布者簽章等適當中繼資料發布，平台就應該能夠執行該軟體。
- 平台會建立強制執行軟體政策的機制，但產品擁有者可以自行決定可以使用哪些軟體來源。產品負責人可以透過政策限制可用軟體來源，但平台不會。
- 平台應能夠產生可安裝任意軟體的產品，包括讓使用者允許任意發布商在裝置上執行的軟體。
實作
我們會從 Software Delivery 說明文件中連結到這個 RFC，在軟體推送專區的設計過程中，也請謹記這一點。
效能
效能不會受到影響。
安全性考量
此 RFC 的實作不會對安全性造成立即影響。從長遠來看，我們預期隨著安全性團隊達成這些目標，我們期望與安全性團隊進行大量合作，因為 SWD 更新機制是保護現場安全漏洞的主要方式。
隱私權注意事項
此 RFC 的實作不會影響隱私權。長期來看，我們期望在達成這些目標時，與隱私權團隊建立大量的合作關係。
測試
此 RFC 的實作不會影響測試。
說明文件
我們會從軟體推送 README 連結到這個 RFC。
缺點、替代項目和未知
我們可為軟體推送領域設定幾乎沒有限制的目標。 我們覺得可以準確呈現堆疊的目前狀態和所需狀態
例如我們將如何與任何可能的第三方軟體發布商整合。如果我們有客戶要求可能性功能，就能更好地解釋這些未知因素。
優先藝術與參考資料
先前發布的 SWD 藍圖相關資訊非常少。不過，先前有許多疊代的套件管理和軟體供應鏈安全性存在。以下是一些先前的圖片：