Field Notes

source

fdroidserver certificate-pinning bypass disclosures

StatusStableUpdatedStands on4 sourcesSupportsnotes

A bundle of two oss-security posts by Fay Stegerman (obfusk), a former F-Droid contributor, documenting a series of proof-of-concept bypasses of AllowedAPKSigningKeys, the fdroidserver mechanism that pins the developer certificate an APK must be signed with before a repository will publish it. Saved copies: the initial PoC disclosure of 2024-04-08, and the follow-up “certificate pinning fundamentally unreliable” of 2025-01-20. The working PoCs and an overview live in the fdroid-fakesigner-poc repository, which is not archived here.

What it shows

The root cause is architectural: fdroidserver verifies an APK’s signature with apksigner but extracts the certificate it pins against with its own Python code, which did not verify what it extracted and checked signature schemes in the reverse order from Android (v1 before v2 and v3). An attacker can therefore craft an APK that passes Android’s verification with one certificate while fdroidserver sees another, defeating the pinning without touching the pinned key.

The timeline matters as much as the mechanism. Jason Donenfeld reported the reversed check order in May 2023 (fdroidserver#1128); it was closed as fixed in May 2024, roughly a year later, after the public PoC. F-Droid’s own patch then introduced further bypasses — incorrect v1 certificate canonicalisation, a signature-file regex mishandling newlines and NUL bytes, and ignored APK Signature Scheme v3.1 blocks — bringing the series to six PoCs by January 2025. fdroidserver 2.3.5 (2025-01-20) patched the known bypasses, but the changelog records no move to the apksig-based combined verify-and-extract approach the disclosures recommend, through 2.4.4 (May 2026).

Both sides’ scope claims are in the record. F-Droid enumerated narrow preconditions for an attack on f-droid.org itself: the app must use Binaries: metadata, have minSdk 24 or higher, the attacker must replace the upstream’s published APK while keeping the build reproducible, and only new installs are reachable, since Android’s signature continuity blocks poisoned updates. Its technical lead’s position was that “AllowedAPKSigningKeys works with no known weaknesses” once v2+ signatures are required. Stegerman’s counter is that this narrows the feature’s documented purpose — letting binary repositories such as IzzyOnDroid cryptographically exclude updates from a compromised upstream — after the fact.

What it is evidence for

This is the strongest technical evidence behind the claim that F-Droid’s tooling quality is a security issue in its own right, distinct from the architectural critique in PrivSec.dev on F-Droid security issues. It bounds that claim at the same time: the bypasses were demonstrated against the tooling, were never observed exploited against a real repository, and the blast radius on f-droid.org is limited to new installs of Binaries: apps. Android app distribution trust models uses it to qualify what the developer-signed publishing path guarantees in practice.

Built on 4 sources (4 external).

Working out connections…