• App signing
• Initial Installs
• F-Droid as built-in app store
• Protecting against malicious contributor-generated data
• HTTPS/TLS configuration
• Security Audits

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.

• a repo is defined by having unique signing key, first and foremost
• HTTPS connections by default
• server only works over HTTPS, HTTP is a redirect
• Android enforces that all apps have a valid signature over the entire contents of the APK file
• Android verifies updates based on the signature of the installed app
• file integrity protected by signed metadata
• As of index-v2, files from the repo are verified based on SHA-256, including icons, screenshots, etc.
• index-v2 uses any algorithm supported by apksigner and android-23 and newer, and relies on OpenJDK’s and Google’s maintenance of the currently valid signing algorithms. When index-v2 was launched, the signature algorithm in use was SHA256withRSA and the digest algorithm was SHA-256. index-v1 is signed by SHA1withRSA. As of this writing, SHA1 are still considered strong against second pre-image attacks, which is what is relevant for index JARs.
• Production signing is handled by reproducible builds of apksigner from Debian.
• signed metadata includes hashes of the app and its signing key
• signed metadata generated on a separate machine (which is fully offline for f-droid.org and guardianproject.info)
• public key for verifying metadata signatures built into F-Droid client app
• signed metadata includes timestamp and expiry
• easy Tor support via Settings
• client-side HTTP ETag cache check so the ETag cannot be abused to track users
• list of official mirrors included in signed metadata, then the client chooses mirrors based on availability and freshness based on local criteria like whether Tor is in use

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

• better handling of index expiry aka “max age”
• pinned TLS certificate built into the client app

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.

• included on the HSTS preload list, so major browsers will only ever use HTTPS for all connections to f-droid.org
• a strong TLS/HTTPS configuration
• a strong HTTP Content Security Policy
• PGP-signature on the initial install download link
• automated regular and random auditing that F-Droid.apk has not been tampered with
• F-Droid Limited controls many potential phishing domains like fdroid.org, f-droid.com, and f-dro1d.org. (donations of more are welcome!)
• website is statically generated to greatly reduce the attack surface
• website is fully functional when JavaScript is disabled in the browser, eliminating all possibility of XSS attacks

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.

• the Android client never runs CSS, JavaScript, or dangerous HTML tags since it displays HTML via android.text.Html.fromHtml() with image loading disabled
• the f-droid.org website protects against malicious and CSS/HTML/JavaScript injection with a strict HTTP Content Security Policy.
• Repomaker filters the texts through Mozilla’s bleach and has a good HTTP Content Security Policy.

HTTPS/TLS configuration

F-Droid has a long history of supporting all Android devices that are still running, that means maintaining compatibility as long as possible. Towards that end, as long as users running current Android versions are not put at risk, old TLS configurations are still supported. This is why we leave TLSv1.0 and TLSv1.1 enabled on our websites. We believe there is no added risk for people who keep their software updated. And a device running Android 1.6 should be able to install an old version of F-Droid, and have a working app store.

Some security scanners will flag this site because TLSv1.1 and TLSv1.0 are still supported. More importantly, this site supports TLSv1.3 and TLSv1.2, both of which offer downgrade protections. On top of that, the latest browsers and F-Droid clients entirely disable TLSv1.1 and TLSv1.0, making it impossible to force those devices to use those vulnerable TLS versions. So the only connections using old TLS versions actually needs those old versions to function. If you are on a device that still needs to use TLS 1.0 or 1.1, then there are already so many well known security vulnerabilities that this one is not particularly interesting.

If you would like to test whether your browser still supports TLS 1.0 or 1.1, click on the links below and see if they give you an error message.

• https://tls-v1-0.badssl.com:1010/
• https://tls-v1-1.badssl.com:1011/

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 “Bazaar 2” project funded by Open Tech Fund included an external public audit from Radically Open Security

4. The NLnet-funded projects “Tracking the Trackers” and “The Search for Ethical Apps” provided an audit performed by Radically Open Security