| 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 - 安全
咨询对象：
- kitlane@google.com
- mckillop@google.com
- hjfreyer@google.com
- 软件交付团队
共同化：
此 RFC 已与软件交付团队以及贡献者一起以文档形式进行了审核。
设计
目标
- 优先考虑客户要求：如果我们有令人信服的客户 需求，则不应害怕重新审视 现有实现或更改策略，只要我们不排除长期目标即可。
- 生产环境中使用一种更新协议：生产环境中的所有设备都使用相同的 更新堆栈和协议进行平台 {1
- 平台更新和非平台更新具有相同的功能：平台 OTA 和独立模块的更新具有相同的功能（渠道、 分阶段发布、垫脚石等），OSS 用户应该可以使用这些功能。
- 尽量减少单体：随着时间的推移，我们打算让平台的大部分内容都可以 独立更新。
- 为可能修改持久状态的攻击提供恢复选项: SWD 堆栈应该能够在启动时自动执行更新，并且对可变数据和其他软件的依赖性最小，以便最大限度地提高从严重漏洞（包括使攻击者能够修改持久状态的漏洞）中恢复的可能性。
- 更新可靠性至关重要：只要我们能够证明更新软件不会损害安全要求，就应该优先更新软件。我们应该优先考虑简单可靠的代码，即使会合理地影响性能；我们的目标是创建最简单的系统，该系统能够正确、安全地执行更新，并满足其他性能要求。 我们应该倾向于安全失败的设计，并允许再次尝试更新，而不是可能因另一次尝试而损坏状态。
- 产品所有者可以选择其政策配置，并随时更改其政策选择，即使设备已在现场也是如此。
- 所有软件都根据有意政策进行验证：所有软件都根据为该类型软件定义的政策进行 检查。这些政策可能包括可执行代码的出处检查、完整性检查、沙盒等。如果没有预定义的政策机制来运行软件，则无法高效运转任何软件。
- 软件来源政策是产品问题
- 平台不限制谁可以发布软件，也不限制需要哪些审批。集中式与去中心化软件来源是产品政策，而不是平台政策。只要软件发布时附带适当的元数据（例如发布者签名），平台就应该能够运行该软件。
- 平台将创建用于强制执行软件政策的机制，但决定哪些软件来源可用的决定权在于产品所有者。产品所有者可以通过政策限制可用的软件来源，但平台不会这样做。
- 平台应该能够生产可以安装任意软件的产品，包括用户允许来自任意发布者的软件在其设备上运行的功能。
实现
我们将从软件交付 文档中链接到此 RFC， 并在软件交付领域的设计过程中牢记此 RFC。
性能
不影响性能。
安全注意事项
此 RFC 的实现不会立即产生安全影响。从长远来看，我们希望在执行这些目标时与安全团队进行大量协作，因为 SWD 更新机制是我们保护现场漏洞的主要方法。
隐私注意事项
此 RFC 的实现不会产生隐私影响。从长远来看，我们希望在执行这些目标时与隐私团队进行大量协作。
测试
此 RFC 的实现不会产生测试影响。
文档
我们将从软件交付 README中链接到此 RFC。
缺点、替代方案和未知因素
我们可以为软件交付领域设定几乎无限的目标。我们认为，这些目标最准确地代表了堆栈的当前状态和我们期望的状态。
存在许多未知因素，例如我们将如何与任何可能的第三方软件发布者集成。一旦我们获得客户对可能功能的要求，我们将能够更好地推断这些未知因素。
在先技术和参考文档
之前发布的有关 SWD 路线图的信息很少。不过，软件包管理和软件供应链安全之前已经过多次迭代。以下是一些在先技术：