| RFC-0134：軟體更新時間依附元件 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 移除時間同步，不再將其視為軟體更新的依附元件。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 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 沒有這個問題，因為 ChromeOS 沒有後備時間，而且沒有在 1970 年有效的 Google TLS 憑證。