F-Droid 的背后是一大堆自动化系统，用于管理从源代码构建数千个应用的过程。这意味着检查数以千计的源代码库，检查它们是否有更新、构建和新版本，并安全地对它们进行集体签名。所有构建都在称为 buildserver 的全新客户虚拟机实例中运行。所有 Gradle 二进制文件和 Android SDK 包都根据我们观察到的 SHA-256 校验和的公开记录进行了验证。透明度记录流程还会根据上游的公共校验和进行验证。

我们的设置几乎完全在 Debian 上运行。 Debian 是自由软件、坚如磐石的服务器和可重复构建的领导者。这使它成为 F-Droid 的天然家园。我们还努力确保我们维护我们使用的软件包，并在 Debian 软件包之上构建我们的流程。这意味着我们与任何使用 Debian 的人共享维护。回馈似乎需要付出更多的努力，但我们的经验是，从长远来看，它会带来回报。 F-Droid 社区可以通过一个小团队来维护很多东西。另一个例子是这个网站本身：它是使用 Debian 中的 Jekyll 包构建的。

如果你在 f-droid.org 上有一个应用，你可能已经注意到所有构建都发生在 5 年前的 Debian 版本上：stretch。我们正在努力升级到最新的 bullseye 版本。这不仅仅是一个简单的 apt-get upgrade，我们还借此机会彻底改革了构建过程，以便应用构建可以使用相对简单的 Debian 安装作为基本操作系统。我们必须提供一个平台来构建数以千计的应用，所以我们不能随心所欲地升级基础镜像。有些应用需要最新、最好的。其他应用需要古老、稳定的基础操作系统。此更改意味着元数据包含尽可能多的构建逻辑，以便应用维护者可以控制所有步骤。为了实现这一点，我们将尽可能多的部分从 buildserver 基础镜像中剥离出来。

我们考虑过提供一系列基础镜像。这是一个可能的解决方案，但它并不像使用任何可用的 Docker 映像那样容易。只有保证是自由软件的基础镜像才是合适的。仅仅指向任意 Docker 镜像将会产生带来专有构建依赖项的可能性，因为无法自动检查任何 Docker 镜像是否是 100% 的自由软件。使用一系列预先批准的基础镜像可以解决这个问题。请记住，这比使用 GNU/Linux 发行版更复杂，因为 Android 应用是交叉编译的。 GNU/Linux 发行版在他们自己的操作系统上构建他们的包。在构建期间，Debian 甚至不允许网络访问，因为所有依赖项都需要来自 Debian 软件包。这种级别的验证是 F-Droid 的目标，而 Maven 致力于实现可重复的 Maven Central 生态系统有很大帮助。

由于 CalyxOS 默认内置 F-Droid，Calyx Institute 也希望确保 F-Droid 能够顺利运行以及使应用开发者愉快。我要感谢 Calyx Institute 赞助我每个月 42 小时的时间来使我们的构建基础设施顺利运行。此外，我将致力于改进签名过程的自动化。我们的签名过程目前是 100% 离线的。虽然这对安全性很好，但它确实减慢了发布过程。借助现代硬件安全模块和服务器设置，可以在不 100% 离线的情况下获得良好的安全性。然后，签名自动化为并行化整个过程提供了可能性，包括运行多个应用构建，以及并行运行构建、索引生成和签名的主要步骤。随着每一项完成，这项工作将逐步部署。所以请耐心等待，你会发现发布的速度越来越快！