针对 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 的贡献。还有一些悬而未决的问题，我们仍在努力解决它们。如果您对可重复构建感兴趣，欢迎贡献。