| RFC-0134：軟體更新時間依附元件 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 不需執行軟體更新，移除時間同步處理。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-07-24 |
| 審查日期 (年/月) | 2021-10-06 |
摘要
這項 RFC 會排除同步處理時間做為軟體更新的依附元件。
提振精神
Fuchsia 裝置會回報固定的「倒停止」時間，直到從網路或即時時鐘同步處理時間為止。回報的時間目前會實作為回報基本映像檔版本的約略時間 (可能為數個月)。
與其他早期啟動使用者不同，系統更新檢查不需要等待時間同步處理。如果更新檢查期間未同步處理時間，套件解析器可能會間接使用回溯時間，做為傳輸層安全標準 (TLS) 憑證驗證的一環。這會產生以下問題：
- 如果回溯時間早於憑證的建立日期，更新就會失敗，並顯示
CertNotValidYet錯誤。由於更新和套件伺服器可能會透過不同名稱存取，因此多個元件中都可能發生這種故障。在這種情況下，如果時間同步處理中斷，裝置會卡住，永遠不會再次更新。 - 過期期間有效的過期憑證可用於提供更新回應和套件。
移除時間同步處理作業做為軟體更新程序的依附元件，如此一來就能解決第一個問題，並提高更新可靠性。
設計
這項 RFC 建議，軟體更新不應仰賴準確的可用時間。
這表示：
允許憑證有未來的有效期限。
請一律使用回溯時間驗證憑證，即使已同步處理時間也一樣。
實作
您必須實作自訂 TLS 憑證驗證器，並在 omaha-client 和 pkg-resolver 中使用。
建構期間，驗證器會從 UTC 時鐘物件的 ClockDetails 取得返回停止時間，並將其做為結構的欄位。
驗證器會使用 WebPKIVerifier 實作 ServerCertVerifier 特徵，並設定傳回返回停止時間的時間函式。如果 WebPKIVerifier 傳回 CertNotValidYet 錯誤，請使用憑證的有效期間建立另一個 WebPKIVerifier 並再次呼叫。
效能
自訂驗證器會直接納入 WebPKIVerifier 來代表滿意度路徑，且如果第一個呼叫傳回 CertNotValidYet 錯誤，只會呼叫 WebPKIVerifier 兩次。
人體工學
無
回溯相容性
API 沒有任何變更。
安全性考量
此設計可接受以下有效憑證：
- 過期的過期 TLS 憑證
- 新的 TLS 憑證
雖然這個情況並不理想，但目前第一個案例可能已發生，因此並非迴歸，而第二個案例的風險非常低。
此外，即使裝置遭人誘騙安裝惡意更新，我們仍會驗證執行作業，因此不會啟動且會還原。此外，我們也復原了保護機制，因此已簽署的舊版版本也無法運作。
請注意，攻擊者持有遭駭憑證和 DNS 控制後，可能會讓時間系統任意接受時間，因此即使確保更新檢查要等待時間同步，並無法協助處理這種情況。
憑證撤銷作業不在這個 RFC 的範圍內，但在另一個 RFC 中是很好的探索領域，儘管這類解決方案可能需要無限期撤銷過期憑證的介紹。
隱私權注意事項
不會影響隱私權。
測試
單元會對自訂憑證驗證器進行廣泛測試，確保之後只有在其他項目有效時，新憑證驗證器才會接受憑證。
針對 omaha-client 和 pkg-resolver 進行整合測試，以驗證更新是否能使用非常久的時間。
說明文件
無
缺點、替代方案和未知
替代方法：等待時間同步處理
在此模型中，我們會等到時間同步後才會更新，雖然這樣可以帶來一些安全性優勢，但由於時間同步處理可能也遭到入侵，並不是太多，但這個模型執行更新所需的時間同步是需要的，但這可能會因為各種原因而發生中斷，導致更新較不可靠。
替代方法：等待時間，但在期限後更新
在這個模型中，我們會等待一段任意時間進行同步，如果時間尚未同步，我們會執行更新檢查。
雖然這種做法可以解決先前替代方法的主要缺點，但在其他方面也相當重要。延遲為任意情況：在啟動迴圈中碰到的延遲時間低於此延遲時間的裝置，也永遠不會更新。
此外，我們還仰賴回溯時間，這可能表示需要放寬憑證驗證的嚴格程度。
先前的圖片和參考資料
ChromeOS 沒有這個問題，因為其沒有回溯時間，而且沒有 1970 年有效的 Google TLS 憑證。