向可重复的 F-Droid 前进

针对 F-Droid 的一个常见批评是,F-Droid 使用自己的密钥对已发布的 APK 进行签名。使用我们自己的密钥并不意味着不安全—我们有良好的记录(并且将密钥保存在专用、气隙、离线的机器上) 而其他人可能并非如此—但这确实意味着我们的用户需要信任上游开发者以外的第三方。

拥有不同的签名也会使用户无法从其他渠道安装更新,从而给用户带来不便;当我们难以为应用提供更新时,这尤其麻烦。开发者有时还需要为了 F-Droid 调整设置,例如禁用应用内更新器或添加 F-Droid 签名以进行验证。

F-Droid 并不是唯一发布使用自己的密钥签名的 APK 的应用商店—Google Play 现在也这样做。通过“app bundle 的代码透明性机制”,Google 提供了一种方法来验证 APK 中的 DEX 文件和本机库是否与开发者提供的那些相同。这确实解决了其中的一些问题,但代码透明性机制并不能保护 APK 中的许多其他重要文件,例如解释性代码或资产。而且与 APK 签名不同,它完全是可选的(对开发者来说是一个额外的负担)并且必须手动执行验证。它也没有解决无法安装具有不同签名的 APK 的不便。

对于这些问题,F-Droid 很早以前就有更好的解决方案了:可重复构建。然而,它从未被广泛使用。原因之一是它听起来很难实现。我们几乎没有可重复的应用(准确地说:只有 6 个),并且其中一些因为使用可重复构建而遇到了问题。基本上,除非上游开发者有兴趣,否则我们懒得提及可重复构建。因此,许多开发者甚至从未听说过可重复构建,更不用说知道 F-Droid 支持它们了,也不会尝试将它们用于自己的应用。

为了回应其中的一些批评,我们开始鼓励新应用使用可重复构建。事实证明,对于许多应用来说,可重复构建并不难实现。在过去的几个月里,我们在 F-Droid 中获得了比以前更多的可重复应用。目前我们无法在客户端突出显示哪些应用是可重复的,因此您可能没有注意到有许多使用上游开发者密钥签名的新应用。如果您启用了一些第三方存储库,例如 IzzySoft,您可能会发现有时您可以从主存储库更新应用,即使您是从另一个存储库安装的。

同时,既然我们遇到了比以前多得多的测试用例,我们也发现了许多影响可重复性的问题。幸运的是,我们还为其中的大多数找到了解决方法,并开发了一些使 APK 可重复的工具,这主要归功于@obfusk 的贡献。还有一些悬而未决的问题,我们仍在努力解决它们。如果您对可重复构建感兴趣,欢迎贡献。