| RFC-0134：软件更新时间依赖项 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 移除了时间同步作为软件更新的依赖项。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-07-24 |
| 审核日期（年-月-日） | 2021-10-06 |
摘要
此 RFC 移除了时间同步作为软件更新的依赖项。
设计初衷
Fuchsia 设备会报告固定的“后备”时间，直到从网络或实时时钟同步时间。目前，报告的时间是指基础映像 build 的大致时间，该时间可能已过几个月。
与其他早期启动时间使用者不同，系统更新检查不会等待时间同步。如果在更新检查期间未同步时间，软件包解析器可能会在 TLS 证书验证过程中间接使用后备时间。这会导致以下问题：
- 如果回退时间早于证书的创建日期，更新将会失败并显示
CertNotValidYet错误。由于更新服务器和软件包服务器可以通过不同的名称进行访问，因此此失败问题可能会出现在多个组件中。在这种情况下，如果时间同步中断，设备将卡住，且永远不会再更新。 - 在后备时间段内有效的过期证书可用于提供更新响应和软件包。
移除时间同步作为软件更新流程的依赖项可解决第一个问题，并提高更新的可靠性。
设计
此 RFC 建议软件更新不应依赖于是否有准确的时间。
这意味着，该功能将：
允许证书的有效期设为未来日期。
始终使用回退时间来验证证书，即使时间已同步也是如此。
实现
需要实现自定义 TLS 证书验证工具，并在 omaha-client 和 pkg-resolver 中使用。
在构建期间，验证程序将从 UTC 时钟对象的 ClockDetails 获取后备时间，并将其保留为结构体的字段。
验证程序将使用 WebPKIVerifier 和返回回退时间的时间函数实现 ServerCertVerifier trait；如果 WebPKIVerifier 返回 CertNotValidYet 错误，则使用证书有效期内的其他时间创建另一个 WebPKIVerifier 并再次调用它。
性能
自定义验证程序只会封装 WebPKIVerifier 以实现正常路径，并且仅在第一次调用返回 CertNotValidYet 错误时调用 WebPKIVerifier 两次。
工效学设计
不适用
向后兼容性
API 没有任何变化。
安全注意事项
此设计将接受以下证书：
- 已过期的 TLS 证书，其有效期晚于回退时间
- 未来的 TLS 证书
虽然这并不理想，但第一种情况今天就可能发生，因此这不是回归问题，而第二种情况的风险非常小。
此外，即使设备被诱骗安装了恶意更新，我们仍会进行验证执行，因此设备将无法启动并会恢复原状。我们还采用了回滚保护机制，因此签名过的旧 build 也不起作用。
请注意，使用已泄露的证书和 DNS 控制权的攻击者可能会诱骗时间系统接受任意时间，因此即使我们让更新检查等待时间同步，也无法解决此问题。
证书撤消不在本 RFC 的讨论范围之内，但在其他 RFC 中是一个值得探索的领域，不过此类解决方案可能需要将已过期的证书列为无限期撤消。
隐私注意事项
对隐私没有影响。
测试
对自定义证书验证程序进行全面的单元测试，确保日后只有在所有其他内容都有效的情况下，它才会接受证书。
针对 omaha-client 和 pkg-resolver 进行了集成测试，以验证更新是否适用于非常久远的时间。
文档
不适用
缺点、替代方案和未知情况
替代方案：等待时间同步
在此模型中，我们将在时间同步后再进行更新，虽然这会给我们带来一些安全优势，但由于时间同步也可能会受到影响，因此优势并不大。不过，此模型会使更新依赖于时间同步，而时间同步可能会因各种原因而中断，这会导致更新的可靠性降低。
备选方案：等待一段时间，但在截止日期之后更新
在此模型中，我们会等待一段时间以使时间同步，如果时间尚未同步，则会在过一段时间后执行更新检查。
虽然这解决了上一个替代方案的主要缺点，但在其他方面却很敏感。延迟时间是任意的：如果设备陷入了比此延迟时间更短的启动循环，也永远不会更新。
此外，我们仍依赖于回退时间，这可能意味着我们需要放宽证书验证的严格性。
在先技术和参考文档
ChromeOS 没有此问题，因为它没有回退时间，并且没有在 1970 年有效的 Google TLS 证书。