| RFC-0133：软件交付目标 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 软件交付领域的一组长期目标。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-09-08 |
| 审核日期（年-月-日） | 2021-10-04 |
摘要
软件交付领域的一组长期目标。
设计初衷
Fuchsia 软件交付系统需要优先考虑客户的需求，并且会继续这样做，但我们也需要设定长期的设计方向，以便在设计时牢记。虽然我们没有针对其中许多目标提出明确的客户要求，但这些目标仍然是我们应该在设计时考虑并随着系统发展而牢记在心的目标。此列表可能会随时间而变化，这没关系。不过，这代表了当今世界的理想状态。
利益相关方
辅导员：
hjfreyer@google.com
审核者：
- abarth@google.com - FEC
- amathes@google.com - 产品
- computerdruid@google.com - SWD
- ampearce@google.com - Security
已咨询：
- kitlane@google.com
- mckillop@google.com
- hjfreyer@google.com
- 软件交付团队
共同化：
此 RFC 以文档形式与软件交付团队以及贡献者进行了审核。
设计
目标
- 优先考虑客户需求：如果我们有令人信服的客户需求，只要不影响长期目标，我们就不应害怕重新审视现有实现或更改策略。
- OTA
- 平台更新和非平台更新具有相同的功能：平台 OTA 和独立模块的更新具有相同的功能（渠道、分阶段推出、跳板等），并且 OSS 用户应该可以使用这些功能。
- 尽量减少单体应用：随着时间的推移，我们希望平台的大部分组件都能独立更新。
- 针对可能修改持久状态的攻击提供恢复选项：SWD 堆栈应能够在启动时自动执行更新，并尽可能减少对可变数据和其他软件的依赖，以便最大限度地提高从严重漏洞（包括使攻击者能够修改持久状态的漏洞）中恢复的可能性。
- 更新可靠性至关重要：只要能证明更新软件不会影响安全性要求，我们就应优先考虑更新软件。我们应优先考虑简单可靠的代码，即使这会合理地影响性能；我们的目标是创建最简单的系统，该系统能够正确、安全地执行更新，并满足其他性能要求。我们应偏向于安全失败的设计，并允许再次尝试更新，而不是可能在另一次尝试中损坏状态。
- 产品所有者决定其产品的策略 ：平台定义了哪些软件更新策略可以表达，并推荐初始策略。产品所有者可以选择自己的政策配置，并随时更改政策选择，即使设备已部署到现场也是如此。
- 所有软件都根据有意设定的政策进行验证：所有软件都根据为相应类型的软件定义的政策进行检查。这些政策可能包括可执行代码的来源检查、完整性检查、沙盒等。任何软件都必须在预定义的政策制度下运行，否则无法运行。
- 软件来源政策是产品问题
- 平台不会限制谁可以发布软件，也不会限制需要哪些审批。集中式与去中心化软件来源是产品政策，而非平台政策。只要软件发布时附带适当的元数据（例如发布者签名），平台就应该能够运行该软件。
- 平台将创建用于强制执行软件政策的机制，但可用的软件来源由产品所有者决定。产品所有者可以通过政策限制可用的软件来源，但平台不会这样做。
- 平台应能够生成可安装任意软件的产品，包括允许用户在其设备上运行任意发布商的软件。
实现
我们将在软件交付文档中添加指向此 RFC 的链接，并在软件交付领域的设计流程中牢记此 RFC。
性能
不影响性能。
安全注意事项
此 RFC 的实现不会立即产生安全影响。从长远来看，在实现这些目标的过程中，我们预计会与安全团队进行大量协作，因为 SWD 更新机制是我们保护现场漏洞的主要方法。
隐私注意事项
此 RFC 的实现不会对隐私权造成影响。从长远来看，我们希望在实现这些目标的过程中与隐私权团队开展密切合作。
测试
此 RFC 的实现不会对测试产生影响。
文档
我们将从软件交付 README 链接到此 RFC。
缺点、替代方案和未知因素
我们可以为软件交付领域设定几乎无限的目标。 我们认为，这些目标最能准确地反映堆栈的当前状态和我们的期望状态。
存在许多未知因素，例如如何与任何可能的第三方软件发布商集成。一旦我们了解了客户对可能的功能的要求，就能更好地推理出这些未知因素。
在先技术和参考资料
之前很少有关于 SWD 路线图的公开信息。不过，之前已经有许多软件包管理和软件供应链安全迭代版本。以下是一些现有技术：