A common criticism directed at F-Droid is that F-Droid signs published APKs with its own keys. Using our own keys doesn’t mean insecure — we have a good track record (and keep the keys on a dedicated, air-gapped, offline machine) whilst others may not — but this does mean that our users need to trust a third party other than the upstream developers.
Having a different signature can also inconvenience users by making it impossible to install updates from other channels; this can be especially inconvenient when we have difficulty providing an update for an app. Developers also sometimes need to tweak their setup for F-Droid, e.g. disabling an in-app updater or adding the F-Droid signature for verification.
F-Droid is not the only app store publishing APKs signed with its own key — Google Play does the same now. With “code transparency for app bundles”, Google provides a means to verify that the DEX files and native libraries in an APK are identical to those the developer provided. This does address some of these concerns, but code transparency does not protect many other important files in the APK, like interpreted code or assets. And unlike APK signatures, it is entirely optional (and an extra burden for developers) and verification must be performed manually. It also does not solve the inconvenience of being unable to install an APK with a different signature.
F-Droid has had a better solution for these problems for quite a while: reproducible builds. However, it was never widely used. One of the reasons is that it sounds difficult to achieve. We had few reproducible apps (to be precise: only 6) and some of them suffered from problems because of the use of reproducible builds. Basically, we didn’t bother to mention reproducible builds unless the upstream developers showed an interest. As a result, many developers never even heard of reproducible builds, let alone that F-Droid supports them, or attempted to use them for their own apps.
In response to some of those criticisms, we started encouraging new apps to enable reproducible builds. It turns out that reproducible builds are not so difficult to achieve for many apps. In the past few months we’ve gotten many more reproducible apps in F-Droid than before. Currently we can’t highlight which apps are reproducible in the client, so maybe you haven’t noticed that there are many new apps signed with upstream developers’ keys. If you have some third-party repositories enabled, e.g. the IzzySoft one, you may find that sometimes you can update the app from the main repository even if you installed it from another one.
Meanwhile, now that we’ve encountered many more test cases than before, we also found many new problems that affect reproducibility. Fortunately we also found workarounds for most of them and developed some tools to make APKs reproducible, mainly thanks to @obfusk’s contributions. There are still some open issues and we are still working hard to solve them. If you are interested in reproducible builds, contributions are always welcome.