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