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