Security Model

The security architecture is based on integrating models proven by Debian and The Update Framework into what the Android OS already provides. The way F-Droid operates is greatly inspired by de facto security model of how reputable GNU/Linux distros like Debian, Fedora, Ubuntu, etc. operate. There is a big emphasis on operating in the public and making everything publicly available. We include source tarballs and build logs when we publish binaries. These are archived as long as possible, for retroactive review. And all of this is mirrored in many places across the internet by many different parties.

While the current setup is already a solid platform, there are a number of improvements that make sense to implement:

In order to defend against an attacker that holds the signing keys for the app repository, there must be a trustworthy source of information to compare against. Reproducible builds means that anyone with the same source code will produce the exact same binary. When paired with an auditing system, it is easy to catch malware inserted in the build process, rather than the source code, like XCodeGhost. Reproducible builds also makes it possible to have all builds of a release binary have the exact same hash. Then any app repository can build apps only from source code, and have a source of verification data from any other app repository building the same app. Building software from source has become cheap enough that many companies like gitlab.com and Travis CI are offering free, automated build services in the cloud. Since the whole F-Droid toolset is free software and designed to be easy to setup, the barriers to setting up automatic auditing are quite low. People in separate areas of the world with different risk profiles can run verification servers to provide more trustworthy information.

The security model of the Build Server Setup and the Signing Process are documented separately.

App signing

  • Apps can be distributed using the developer’s own signatures when the builds are fully reproducible.
  • By default, the “publish” server will generate and manage a signing key for each individual app. These signing keys are only shared between apps when specifically configured to do so using the keyaliases mechanism in config.yml.
  • All apps are signed by the key devoted to that app unless the upstream specifically requests multiple apps be signed by the same key, and the fdroiddata maintainers approve it.
  • For f-droid.org, all app signing is done on a dedicated, air-gapped, offline machine.
  • At any time, the developer’s own signatures may be added their app(s) in f-droid.org once reproducible builds have been achieved. Additionally, releases signed by the f-droid.org key will continue to be shipped.
  • In the official F-Droid client app, the developer’s own signature is the default for fresh installs.
  • We encourage app developers and maintainers to think about whether they want to use a special Application ID for the app when published in f-droid.org to avoid conflicts with other versions. One common pattern is to add .fdroid to the end of the Application ID via a Gradle Build Flavor.

Initial Installs

Most users of F-Droid download the APK from f-droid.org and install it. This is a potential vector of attack that built-in app stores do not have. Therefore, many additional security precautions are taken to make it as hard as possible to exploit this vector.

F-Droid as built-in app store

When F-Droid is built into Android, either as part of the ROM or by flashing an OTA update, it no longer needs “Unknown Sources” enabled to function. This is the preferred method of operation, so we aim to make it as easy as possible for users to run F-Droid this way. Flashing the OTA package for F-Droid Privileged Extension has the same or lower risk profile as installing the standard “gapps” package that many people flash onto custom ROMs. So this delivery method does not increase the risk profile of those users.

On top of this, F-Droid makes it as easy as possible to build it into ROM projects. It is already included in CalyxOS, Replicant, LineageOS for microG and Fairphone Open.

Protecting against malicious contributor-generated data

The app descriptions are submitted by all sorts of people, and they can also be taken from the app’s source repository. This data is ultimately delivered to the Android client or the user’s browser via f-droid.org.

Security Audits

  1. There was a quick, informal security audit (archived) done in 2013 by then graduate student Daniel McCarney aka pd0x.

  2. The first “Bazaar” project funded by Open Tech Fund included an external public audit from Cure53

  3. The second “Bazaar2” project funded by Open Tech Fund included an external public audit from Radically Open Security