Upcoming Security Audit

We have started the process of the second security audit of the
F-Droid setup. The audit will be conducted by
Radically Open Security,
which is a natural partner for F-Droid since they share our focus on
free software and open processes. Once we receive the results and
have addressed any issues found, we will publish the full, unedited
audit report here. Thanks to Open Tech Fund
for covering the costs of hiring the auditor.

For more information about F-Droid’s security practices on in the
documentation about the
Security Model.

Looking back at the first security audit

We received an
external audit in 2015
from Cure53, provided by the
Open Tech Fund. This was the first full
security audit of the core security practices of F-Droid. On top of
the core, the focus on the audit was on the new, experimental features
that opened up F-Droid as an ecosystem, moving away from the central
server model.

This audit confirmed the security of core pieces, as listed on the top
of this page. That is a little hard to see since the report only
discussed the vulnerabilities that were discovered. This audit did
find critical issues in the website, opt-in beta features, and some
minor features like fdroid import, which is only used by a couple of
people and never on core infrastructure. It is important to note that
the website issues never meant that getting apps via the Android
client app was affected. Most importantly, all of the security issues
were fixed. The audit also demonstrated that building a system with
user-generated inputs is hard to fully secure. Our focus is removing
anything that opens up attack vectors to the external data sources
like app source repos.

The normal way of using F-Droid was not affected. For example,
regarding BZ-01-004 Command Injection Flaw, the root-based
installation method was marked experimental, not widely used, and
removed around not long after the report came out. The BZ-01-002 and
BZ-01-003 TOFU issues never applied to the default app repos since
the repo keys are built into the client app.

The following issues all assume developer- or publisher-level access.
We do not claim to protect against attackers with that level of
access. People in those roles can always publish malicious code
directly, without resorting to complicated exploits.