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.
