又一个月过去了，我们已经完成了很多工作。没有什么大的宣布，但有很多渐进的进展、自行车棚和会议。我们一直在为 Alpine 3.15 中的多项计划奠定基础，并与其他团队合作寻找漏洞信息共享的前进道路。到目前为止，这次更新最大的消息是新生的 Alpine Core Team 正式分裂为 Alpine Council 和 TSC。我是 TSC 的成员，代表安全团队。我们现在已经召开了两次 TSC 会议，并且 TSC 已经在解决安全团队提到的几个问题。在确定 TSC 的工作流程方面还有很多工作要做，但我们正在取得进展。安全团队提到 TSC 的第一个问题很重要：安全团队希望弃用 sudo 以支持 doas。这是因为 doas 是一个更简单的代码库：虽然 sudo 有 174k 行代码，但 doas 只有 2500 行，包括可移植层。由于两者都是 SUID 程序，因此安全团队更愿意支持更简单的 doas 而不是更复杂的 sudo，这希望是有道理的。 doas 必须获得与 /etc/sudoers.d 等效的文件，以便维护者脚本可以利用它来执行自动重启服务等操作。我一直在与上游合作以启用这种支持，这应该会在本周晚些时候登陆 Alpine。 cloud-init 必须适应支持 doas。这是因为云镜像没有启用root用户，所以需要有一个工具来允许升级到root，比如老生常谈的sudo -si。希望能很快实现 cloud-init 的插件：我们已经与 cloud-init 维护者就此进行了一些讨论。我希望其他发行版能跟随我们的脚步并弃用 sudo 以支持 doas。虽然我们应该尽量避免使用 SUID 程序，但更简单的 SUID 程序仍然比像 sudo 这样复杂的程序要好。虽然不直接与安全相关，但由于安全团队不为测试存储库提供安全支持，我向 TSC 提出了一个问题，以定义测试包的截止日期，他们必须离开测试并转到社区或主要，或者他们必须从测试中删除。这是因为人们为测试贡献了包，然后我们再也没有收到这些人的消息，而他们的包在测试中基本上没有维护。当我们由于库更改其 soname 而必须进行重建时，这会给安全团队带来问题。
目前预计 TSC 将在两周后的下一次会议上讨论这个问题。希望这转化为软件包离开测试的最后期限。目前，我们仍然专注于使安装介质具有可复制性。在这方面，我查看了 kpcyrd 的补丁，以使 apk 索引可重现。经过一些讨论，这个补丁被 apk-tools 接受，并包含在 2.12.6 及更高版本中。下一步仍然是在 Alpine 中构建信息的设计和实现。随着 apk-tools 3 的到来，我们正在讨论使用包本身中的结构化数据而不是磁盘上的实际文件来表示 buildinfo 数据。一旦特定的设计讨论完成，我们将努力将其推送给边缘构建者，并开始在重建后端上工作。就部署的更改而言，这里没有太多可谈的。事情进展顺利，问题很少。然而，在幕后，我们仍在与许多利益相关者合作，以实现实时漏洞信息共享。无论出于何种原因，这是一个政治不断变化的话题：例如，我们有分布式弱点归档项目，该项目现已停止并被通用漏洞标识符取代。运行 UVI 的人想要我们想要的东西：基于推送消息和 JSON-LD 的实时漏洞数据共享，但他们遇到了同样的困难，我让每个人都参与 JSON-LD 部分。不幸的是，JSON-LD 部分是所有这一切中最重要的部分，因为它允许所有人参与：虽然 Go 和 OSV 团队提出的新模式是对 CVE v4 的重大改进，但设计者特别考虑了 URI，并且因此链接数据，是有害的。
但是，链接数据确实可以让我们扩大规模并跟踪所有漏洞。虽然域确实可以消失，但可以使用 JSON-LD 存档该数据：实现允许将某些 URI 模式替换为其他模式（例如 archive.org）。目前，我们每年跟踪大约 20,000 到 30,000 个 CVE，但实际上，每年可能发现数百万个漏洞。拥有一组集中的、守门的漏洞数据库根本无法适应这一现实。通过使用链接数据，可以简单地浏览 JSON 文档并发现有关漏洞的更多信息：这本身真的很有帮助。但是，当您意识到可以在其他上下文（例如恶意软件数据库）中引用漏洞数据时，这变得更加令人敬畏：现在，恶意软件研究人员可以跟踪 CVE-2021-34481 的节点并获取有关 Print Spooler CVE 的结构化数据，而且完全透明。我不能过分强调这就是它必须的样子。我们永远不会达到跟踪每个漏洞的地步，除非它是一个像这样的开放系统，以与 FOSS 相同的精神构建，但用于数据。不幸的是，我怀疑在我们到达那里之前至少还会有另一轮讨论。一旦这些问题得到解决，并且明确的前进路径是显而易见的，我们将发布 secfixes-tracker 0.4，这使得安全数据以上面讨论的标准化 JSON-LD 格式可用。 Timo 继续在 apk-tools 3 上取得进展。 Alpine 3.15 很有可能会附带 apk-tools 3，而且这种可能性一直在增加。
自上次更新以来，我们得出结论，apk-tools 3 使用的新索引格式是可重现的。我还与 Timo 讨论了将安全修复数据引入新的 apk-tools 索引的问题，我们正在开始为此设计。这将启用 apk 列表 --upgradable --security 功能，我现在已经谈过几次了。我计划在下周左右发表一篇博文，展示 apk-tools 3 索引和 apk-tools 3 软件包的可重现性。我还一直致力于为 ADB 格式编写规范，以便其他人可以为它编写自己的解析器。这将很快成为 MR 的上游。安全团队的部分职责是从 MITRE 获取 CVE。我们正在考虑成为 CVE 编号机构以改进获取 CVE 的过程，但 CNA 使用的过程有点笨拙，因此我们可能不会真正做到。 7 月，我们针对 Alpine 软件或特定于 Alpine 的打包问题请求了两个 CVE：CVE-2021-36158：xrdp 包为每次安装生成相同的公钥和私钥对。这是通过将密钥对生成移动到维护者脚本中来解决的。感谢 Leo 修复它！ CVE-2021-36159：Samanta Navarro 向 Alpine 和 FreeBSD 报告了 libfetch 中的一个漏洞。我们为 Alpine fork 请求了 CVE，但随后 FreeBSD 决定对原始 libfetch 也使用相同的 CVE。作为协调此漏洞的副作用，我建议创建一个统一的 libfetch 项目，所有用户都可以在其中协作维护。我与 Alpine 安全工作相关的活动目前由 Google 和 Linux 基金会赞助。没有他们的支持，我将无法在 Alpine 全职从事安全工作，谢谢！我也感谢他们最近对 kpcyrd 的赞助，kpcyrd 是 Alpine、Arch、Debian 和 reproducible-builds.org 的贡献者！