Field Notes

entity

F-Droid

StatusStableReviewdue UpdatedStands on15 sourcesSupportsnotes

F-Droid is a free and open-source Android app repository that builds apps from publicly available source code and distributes the resulting binaries. It is the primary Android distribution channel organized around Source-to-binary correspondence: proving that the binary a user installs was built from the source they can inspect.

Security model

F-Droid’s architecture is inspired by the Debian model of operating in public and making everything auditable. Source tarballs and build logs are published alongside binaries and archived for retroactive review. Repository metadata is signed, and the official client verifies hashes and certificates before installing or updating apps.

App signing follows a per-app key model by default: the publish server generates and manages a separate signing key for each app, so compromising one key compromises one app, not the repository. For f-droid.org, all signing happens on a dedicated, air-gapped, offline machine, which has no network path in either direction: unsigned builds arrive and signed artifacts leave on removable media carried by a person. That batching is a direct cause of the update latency the project is criticized for. Because the per-app keys share one keystore on that one host, the custody risk is many keys in a single vault rather than one key for everything, a distinction Android app distribution trust models develops alongside the comparable custody arrangement in Play App Signing.

The security model’s own documentation acknowledges that against an attacker holding the signing keys, there must be a trustworthy source of information to compare against. Reproducible builds supply that backstop: a binary pushed from a compromised signing host will not match an independent rebuild of the public source.

Reproducible-builds transition

Coverage has grown steeply: about twenty apps in late 2022, 191 by September 2023, roughly 21% of the main repository at the end of 2025, and 32.6% — 1,339 of 4,113 published apps — when counted directly in July 2026. A per-app reproducibility status dashboard shipped in May 2025. When a build is reproducible, F-Droid ships the developer’s own signed binary alongside an identical rebuild, giving the user both continuity of publisher and verified correspondence to source.

Tooling and operational record

The architectural debate has a concrete underside in a series of episodes between 2022 and 2025. They are the strongest version of the claim that F-Droid’s problems are implementation quality rather than design, and each also has a bounded reading.

Certificate pinning. Between May 2023 and January 2025, the AllowedAPKSigningKeys mechanism — the check that pins the developer certificate on the developer-signed publishing path — was bypassable in six demonstrated ways, because fdroidserver verified signatures with apksigner but extracted the pinned certificate with custom code that checked signature schemes in the reverse order from Android. fdroidserver pinning bypass disclosures documents the series: the underlying bug sat for a year after being reported, F-Droid’s own patch introduced further bypasses, and the known ones were fixed only in fdroidserver 2.3.5 (January 2025). The blast radius stayed theoretical: exploiting f-droid.org itself required a compromised upstream that still produced a reproducible build, and Android’s signature continuity limited any success to new installs.

Dependency poisoning. The one realized supply-chain incident in the main repository did not touch signing or the build host at all. In August 2022 the F-Droid build of the Nextcloud News app shipped a beacon injected into a poisoned copy of a stale dependency published to JitPack under a hijacked namespace; the developer’s own APK, built against a warmed dependency cache, was clean. Malware in F-Droid build of Nextcloud News App records the incident: the binary corresponded exactly to the published source, because the attack surface was the dependency closure that correspondence does not cover.

Update automation credentials. In late 2024 F-Droid disclosed that its checkupdates automation had in specific situations leaked a private deploy key granting direct push access to fdroiddata. The key was revoked, no unauthorized commits were found in the account activity or the local source copies, and the workflow was reorganized so the bot files merge requests with least privilege instead of pushing directly.1 Critics cite the leak as operational sloppiness; the disclosure itself was prompt, public, and remediated.

Moderation is scanning, not review. F-Droid’s pipeline fetches, scans, and builds automatically; there is no per-release human review, which two episodes illustrate from opposite sides. In June 2023 a scanner false positive flagged Shattered Pixel Dungeon with a known-vulnerability anti-feature and an uninstall recommendation — the second such false positive for that app — corrected within days but not before the developer publicly disowned the F-Droid distribution over it.2 In the other direction, WireGuard shipped a self-updater that violated the inclusion policy for roughly half a year in 2023 before anyone flagged it, as wireguard inclusion policy violation records. The sharper current instance is neither a false positive nor a missed violation but a correct flag with an uncomfortable cause: in late 2024 Fennec and Mull sat for about two months with 42 known Firefox CVEs because the inclusion policy’s built-from-source toolchain rule blocked the update, and the KnownVuln mechanism’s answer — recommending uninstall of the only builds available — was accurate and useless at once.3

Client software. The stable full client still targets API 30 with an in-code ExpiredTargetSdkVersion suppression, the Basic flavor targets 35, and the 2.0 rewrite — in alpha since May 2026 — targets 37.4 The website still lists raw install-time permissions verbatim, so the misleading-display concession in fdroid-website mr 834 remains unimplemented there. And fdroidserver’s metadata is single-signer: v3 key rotation is preserved in copied signature blocks but cannot be expressed in the pinning schema, so moving an app to the developer-signed path still costs its users a reinstall.5

Build infrastructure lag. The concrete form of the “outdated infrastructure” critique is tooling drift blocking current app releases. When Android Gradle Plugin 8.12 began requiring CPU instructions the buildserver lacked in mid-2025, builds of dozens of apps were blocked for months until new build hardware arrived in November 2025 and Google shipped a compatible aapt2 in AGP 8.13.2.6 The same episode shows the counter: the decade-old core server the critique describes was replaced in 2025.

Developer relations. The defections are real but specific. WireGuard’s developer called the project “basically rotted” and built his own update channel (wireguard inclusion policy violation); Catima’s maintainer, a former F-Droid contributor, objected that the reproducibility status page presents F-Droid rebuilding its own output as “reproducible” without distinguishing who signed the result;7 IronFox declined main-repo inclusion in January 2025 citing build delay and the PrivSec.dev critique.8 None of these accounts alleges that F-Droid itself shipped a compromise; the complaints cluster on update latency, tooling quality, and governance. The feud between the project and the GrapheneOS-adjacent critics has a documented origin in a July 2022 website merge request: a substantive technical exchange whose points F-Droid’s own author conceded, moderated with comment deletions that each side remembers differently.

Critique and tradeoffs

PrivSec.dev on F-Droid security issues is the most widely cited technical case against relying on F-Droid. Android app distribution trust models evaluates the relative trust properties of F-Droid, the Play Store, and other channels on the correspondence axis. The central tradeoff is that F-Droid’s source-build model can prove what no other mainstream channel proves, at the cost of update latency, a signing-host concentration risk, and an additional party in the trust chain for the majority of apps not yet built reproducibly.

  1. Security of the updates automation, F-Droid, 2024-12-13. ↩

  2. Shattered Pixel Dungeon issue 1394 and fdroidserver#1103; F-Droid merged the developer’s disclaimer into the app description and tracked process changes in fdroidserver#1139. ↩

  3. F-Droid forum: Fennec vulnerability (October 2024), with staleness tracked by the DivestOS F-Droid freshness list. ↩

  4. fdroidclient app/build.gradle at 1.23.2 and the master’s targetSdk = 37. ↩

  5. fdroidserver#1342, which records that “the metadata schema can’t currently express ‘this old key can rotate to this new one’”, and fdroidserver#1254, proposing v3 rotation. Open issue trackers state the maintainers’ understanding of a limitation at the time of writing, and both threads can gain later comments that change the picture. ↩

  6. F-Droid admin issue 593, updated after the hardware replacement announced in TWIF 2025-11-13. ↩

  7. Catima issue 2608. An upstream maintainer’s objection filed against their own app’s listing, so it is a participant’s complaint rather than a neutral audit, and the thread remains open to later replies. ↩

  8. PrivSec.dev on F-Droid security issues; IronFox inclusion discussion, which also records GrapheneOS’s and the PrivSec.dev author’s current positions in the thread. ↩

Built on 15 sources (15 external).

Working out connections…