自动化是一个让 F-Droid 的小团队向数百万用户提供应用的关键因素。我们重新开发了 @checkupdates-bot 以替代 F-Droid 自动化中一个旧组件：checkupdates。它遍历所有现有应用，检查它们是否设置了自动更新，并为自动更新的应用运行自动生成新构建项的流程。这会添加到 fdroiddata，然后由生产 buildserver 处理以构建并发布应用。

因为遵循最小特权原则的系统能提供最好的安全性，我们最近围绕此原则重新组织了设置和工作流以使 @checkupdates-bot 拥有它所需要的最小特权。checkupdates 流程现在在它自已的单独项目中运行，与 fdroiddata 和任何其它 gitlab.com 上的 F-Droid 项目分开。它现在只向它自己的专用项目推送提交，然后为每个应用向 fdroiddata 创建一个合并请求。我们的自动 CI 流程和信任的人类审核者现在对更新和新应用使用同样的流程。

与此同时，我们移除了一个代码中的关键的晦涩的东西：stats/known_apks.txt。这个文件是每个应用添加到存储库里时存放日期的地方。这个文件在 buildserver 上更新并在 fdroiddata 上维护。这个信息也在索引文件里所以我们改为从那里获取它。这意味着我们可以移除 fdroiddata 中使用的最后一个部署密钥。我们的运作不再需要在 fdroiddata 中有任何部署密钥。

我们顺便通过合并请求添加了一些额外的检查。例如，现在每当添加或修改一个图像文件，CI 会检查图像是否包含任何 EXIF 元数据，这可以被用作漏洞利用向量。我们也添加了一些额外的措施以确保关键文件的更改需要通过合并请求得到人类审核。

安全问题的启发

大约一个月前，@SomberNight 在一个私密议题中向我们报告了一个安全问题。我们感谢这个详细的报告，并且想强调他们后续的努力帮助。在特定情况下，之前的设置会泄露有 fdroiddata 直接提交权限的私有部署密钥。我们立即吊销了这个密钥，然后移除了与私钥关联的 @fdroidci 用户的所有权限。我们也调查了我们能跟踪的所有线索，检查是否有人使用此私钥在 F-Droid 中插入了什么东西。我们搜索了 @fdroidci 用户的所有活动，没有发现证据表明有未授权提交。

为了更加确定，我们做了一些额外的调查。因为 checkupdates 作为 gitlab.com 上 fdroiddata 项目的一部分运行，恶意应用构建配方也可能读取包含了私钥的 CHECKUPDATES_SSH_DEPLOY_KEY 变量。我们检查了 fdroiddata 的历史但没有发现渗透迹像。我们要求应用从源码构建，且源码由 Git 之类的管理系统中。这确保一个包含历史的本地源码保留在我们的 buildserver 上。我们搜索了我们的本地源码，没有找到证据表明任何应用进程试图获取 checkupdates 私钥。

你有更多关于要搜索的东西的想法吗？请深入研究并告诉我们如果你找到了任何可疑的东西。公开工作意味着任何人都可以自由调查并得出结论，并向一个更安全的 Android 自由软件生态做出贡献。