| RFC-0134：軟體更新時間依附元件 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 移除時間同步功能，不再視為軟體更新的依附元件。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-07-24 |
| 審查日期 (年-月-日) | 2021-10-06 |
摘要
這項 RFC 會移除時間同步功能，不再視為軟體更新的依附元件。
提振精神
在 Fuchsia 裝置同步網路或即時時鐘的時間之前，裝置會回報固定的「回溯」時間。目前的時間回報功能會回報基本映像檔建構作業的預估時間，但這可能會是幾個月前的時間。
與其他早期啟動時間使用者不同，系統更新檢查不會等待時間同步。如果在更新檢查期間未同步時間，套件解析工具可能會間接使用備用時間，做為 TLS 憑證驗證的一部分。這會導致以下問題：
- 如果備用時間早於憑證建立日期，更新作業就會失敗，並顯示
CertNotValidYet錯誤。由於更新和套件伺服器可能會透過不同的名稱存取，因此這個錯誤可能會發生在多個元件中。在這種情況下，如果時間同步處理作業中斷，裝置就會卡住，且不會再更新。 - 在備用時間內有效的已過期憑證，可用於提供更新回應和套件。
移除時間同步作業 (做為軟體更新程序的依附元件) 可解決第一個問題，並讓更新作業更可靠。
設計
這項 RFC 建議軟體更新不應依賴準確的時間。
也就是說，這項功能會：
允許憑證的有效期間在未來。
一律使用備用時間來驗證憑證，即使時間已同步也一樣。
實作
您必須實作自訂 TLS 憑證驗證器，並在 omaha-client 和 pkg-resolver 中使用。
建構期間，驗證器會從世界標準時間時鐘物件的 ClockDetails 取得備用時間，並將其保留為結構體的欄位。
驗證器會使用 WebPKIVerifier 實作 ServerCertVerifier 特徵，並搭配傳回備用時間的時間函式，如果 WebPKIVerifier 傳回 CertNotValidYet 錯誤，則使用證書有效期間內的時間建立另一個 WebPKIVerifier，然後再次呼叫。
成效
自訂驗證器只需為順利路徑包裝 WebPKIVerifier，且只會在第一次呼叫傳回 CertNotValidYet 錯誤時呼叫 WebPKIVerifier 兩次。
人體工學
無
回溯相容性
API 沒有任何變更。
安全性考量
這項設計會將下列憑證視為有效：
- 已過期的 TLS 憑證，其時間晚於備用時間
- 未來的 TLS 憑證
雖然這不是理想情況，但第一種情況今天就會發生，因此並非回歸，而第二種情況的風險也非常低。
此外，即使裝置遭到誘騙而安裝惡意更新，我們仍會執行驗證，因此裝置不會開機，並會恢復原狀。我們也提供回溯保護機制，因此已簽署的舊版也不會運作。
請注意，攻擊者使用遭到入侵的憑證和 DNS 控制項，可能會欺騙時間系統接受任意時間，因此即使我們讓更新檢查等待時間同步，也無法解決這個問題。
憑證撤銷不在本 RFC 的討論範圍，但在其他 RFC 中會是個值得探討的領域，不過這類解決方案可能需要將過期憑證列為無限期撤銷。
隱私權注意事項
不會影響隱私權。
測試
全面測試自訂憑證驗證器，確保日後只在所有其他項目皆有效的情況下，才會接受憑證。
針對 omaha-client 和 pkg-resolver 進行整合測試，確認更新功能可在非常久以前的時間運作。
說明文件
無
缺點、替代方案和未知事項
替代做法：等待時間同步
在這個模型中，我們會等到時間同步後才更新，雖然這會帶來一些安全性優勢，但由於時間同步也可能遭到入侵，因此實際上並沒有太大幫助。此外，這個模型會讓更新作業依賴時間同步，而時間同步可能會因各種原因而中斷，導致更新作業的可靠性降低。
替代做法：等待時間到達，但在期限過後才更新
在這個模型中，我們會等待一段時間讓時間同步，如果時間尚未同步，則在一段時間後執行更新檢查。
雖然這可解決先前替代方案的主要缺點，但在其他方面仍有缺點。延遲時間是任意的：如果裝置陷入的啟動循環時間比這個延遲時間短，也永遠不會更新。
此外，我們仍仰賴備用時間，這可能表示我們需要放寬憑證驗證的嚴格程度。
既有技術與參考資料
ChromeOS 沒有這個問題，因為它沒有備用時間，而且沒有在 1970 年有效的 Google TLS 憑證。