Field Notes

source

PrivSec.dev on F-Droid security issues

StatusStableReviewdue UpdatedStands on3 sourcesSupportsnotes

PrivSec.dev is a community privacy and security blog adjacent to the GrapheneOS community, though the article carries a disclaimer of independence from that project. This page, “F-Droid Security Issues,” is the most widely cited technical case against relying on F-Droid as a primary Android app source. A saved copy is preserved here; the .raw.html companion is the provenance copy. The page is stamped “last updated July 18, 2026,” but its substance describes the state of F-Droid around mid-2022.

What it argues

The article makes a layered case:

  • F-Droid signs most apps with its own keys, so a user trusts both the developer and F-Droid; it frames this added party as a net loss, reasoning that “the fewer parties, the better.”
  • The inclusion policy forces developers to strip proprietary libraries, producing divergent builds that can lag upstream on security fixes.
  • Air-gapped, human-gated signing delays updates, and some projects decline inclusion for that reason.
  • The build infrastructure is called outdated, citing a 2022 window when the build guest VM ran an end-of-life Debian LTS release.
  • The F-Droid client targets a low Android API level, weakening sandbox and permission hardening.
  • Technical complaints: no TLS certificate pinning, slow adoption of modern APK signature schemes, and metadata signing weaknesses in the v1 index format.
  • Install-time permission display is called misleading in a runtime-permission era — a point conceded in substance by the F-Droid author who opened the discussion it traces to.

It recommends preferring the Play Store, with direct developer builds or curated stores as secondary options, and treats reproducible builds as a marginal case.

What it is evidence for

The article is a reliable catalogue of F-Droid’s structural tradeoffs and a good statement of the trusted-party framing that dominates GrapheneOS-adjacent security writing. It is useful precisely as the position that Android app distribution trust models tests against the Source-to-binary correspondence property.

Limitations

Two limitations bear on reliance. First, the content is dated despite the recent timestamp. Its “very few reproducible builds” was true when written; by July 2026 the developer-signed share of the main repository was 32.6%, a per-app reproducibility dashboard shipped in May 2025, and the index-v2 format the article calls unproven has shipped. Several claims describe conditions that no longer hold. The “outdated infrastructure” claim is the clearest example. Its sole basis is a five-month window in 2022 when the build guest VM ran end-of-life Debian Stretch; it was never a description of a standing condition. F-Droid replaced its decade-old core build and publish server in 2025, migrated build orchestration to Buildbot, and decoupled the architecture from any single virtualization platform, so the one aging system the claim gestures at is the system that was retired. Repeating the claim in 2026 cites a resolved incident as current state. Second, the framing prices Source-to-binary correspondence at zero. Its central recommendation follows only under that unstated premise, which the article never defends.

The article also concedes the point that would decide its trusted-party argument. It records that Play “now manages the app signing keys too,” that Play App Signing has been required for new apps since August 2021, and that F-Droid controls its signing servers “much like Play App Signing.” That concession leaves both channels with the key held by the distributor, so the party count cannot separate them, and the comparison falls back to what each signature attests to. The durable complaints, treated in Android app distribution trust models, are update latency for hard-to-build apps, the stable client’s expired target SDK, the stale-dependency hazard, and the added-party concern for apps not built reproducibly. A July 2026 currency check in that note found routine update latency down to two to five days, the infrastructure instance retired, and the “outdated main download” claim retired in form, while the website permission display, missing key rotation, and tail latency for browsers remained as described.

The author’s 2025 restatement

In the IronFox inclusion thread of January 2025, the article’s author defended its currency in place: the build server was “still end of life” (Debian Bullseye, EOL August 2024, with the bootstrap repository’s README updated to Bookworm only that October and stale references remaining), the builder gained attack surface by provisioning Tor, and “the general malpractices remain the same.” In the same exchange he conceded the client target-API point after F-Droid bumped it to 34, and cited the Nextcloud News incident as evidence the audit system is “pretty meaningless” — an attribution that incident’s own resolution does not support, since the poisoned dependency entered through the app’s published build configuration, not F-Droid’s infrastructure. An F-Droid-side contributor’s counter in the same thread was that the article is “stuck in time with the same arguments from 2021.” Both statements predate the 2025 server replacement, which retired the system the infrastructure claim gestures at.

Built on 3 sources (3 external).

Working out connections…