The security architecture is based on models proven by Debian, The Update Framework , and others:

• 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
• 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.

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.

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