F-Droid is an installable catalogue of FOSS (Free and Open Source Software) applications for the Android platform. The client makes it easy to browse, install, and keep track of updates on your device.
The diminished security resulting from the increased likelihood of a (single point of failure) supply chain attack.
Yes its possible for malicious devs to trojan apps, but due to apk signing it is much more difficult for a third party entity to induce a supply chain attack, which is my real concern when it comes to phone security.
If you have a lower threat model, this post isn’t for you…
The author of this article completely misses the point of F-droid. They clearly are used to a world of proprietary software that takes “security” over freedom
So yes I did read the article and no it doesn’t change anything. If your going to make an argument you shouldn’t just link to someone else’s work. Part of the problem with the internet is no one thinks for tuemselves
Sure, I’ll spell it out for you since apparently the point went right over your head. Fdroid devs are a single point of failure by signing every application themselves. This introduces a potential for supply chain attack, not to mention Fdroid running on EOL servers.
When you use an individual dev repo, you can avoid any trojanized apps from Fdroid because the developers maintain their own infrastructure and sign their own apks.
The reason F-Droid builds from source is to ensure that they can enforce their inclusion criteria. If you go outside F-Droid you lose that guarantee. For example, self-published apks in github or google play may contain anti-features or proprietary code that are forbidden by the F-Droid standards.
From another point of view, what you call a single point of failure is a third party that represents the interests of the user community, independent from individual developers. This is the same model used in GNU/Linux distributions, and Drew DeVault explains here the role that software distributions play in the free software community.
Of course, this represents a trade-off, in that you are placing trust in the software distribution instead of or in addition to the upstream developer. The question is, how can you solve the problem without foregoing F-Droid’s inclusion standards? The answer is reproducible builds, where F-Droid builds from source and compares to the developer’s apk, and publishes the developer’s apk with their signature if the build reproduces successfully.
Until Reproducible builds are the norm in the Android free software world, I accept the trade-off because I value having software freedom in my computing, and I know I can’t trust upstream developers to care about that as much as F-Droid or I do.
Sure, atleast you admit there’s a trade off (security) for (FOSS) and maybe some additional privacy.
People should be made aware of the risks and choose according to their threat models, which is why I’ve highlighted some of these issues to begin with.
Everything the F-droid team does is out in the open. Your welcome to audit it once in a while and suggest changes to make it better. I’m sure they wouldn’t mind the help.
F-droid is the best tool we got. Its not a silver bullet but it is better than anything else I’ve seen
Love F-Droid but be aware of the risks and always try to use a developer repo when possible…
https://privsec.dev/posts/android/f-droid-security-issues/
[This comment has been deleted by an automated system]
Doesn’t affect the end user… beyond diminished security. Are you implying I should trust Fdroid devs as much as I would trust Google devs?
[This comment has been deleted by an automated system]
The diminished security resulting from the increased likelihood of a (single point of failure) supply chain attack.
Yes its possible for malicious devs to trojan apps, but due to apk signing it is much more difficult for a third party entity to induce a supply chain attack, which is my real concern when it comes to phone security.
If you have a lower threat model, this post isn’t for you…
[This comment has been deleted by an automated system]
If you think Fdroid security is on par with Google security… then I got a bridge to sell you
How does a supply chain attack work?
An upstream compromise that affects downstream hosts. A good example is the NPM supply chain attack -> https://hackaday.com/2021/10/22/supply-chain-attack-npm-library-used-by-facebook-and-others-was-compromised/
I actually would go for the main repo as all the software in the main repo is reviewed by the main Dev team
Did you even read the article? F-Droid signs all the apps in the main repo…
The author of this article completely misses the point of F-droid. They clearly are used to a world of proprietary software that takes “security” over freedom
So yes I did read the article and no it doesn’t change anything. If your going to make an argument you shouldn’t just link to someone else’s work. Part of the problem with the internet is no one thinks for tuemselves
Sure, I’ll spell it out for you since apparently the point went right over your head. Fdroid devs are a single point of failure by signing every application themselves. This introduces a potential for supply chain attack, not to mention Fdroid running on EOL servers.
When you use an individual dev repo, you can avoid any trojanized apps from Fdroid because the developers maintain their own infrastructure and sign their own apks.
That’s called… D I S T R I B U T E D T R U S T
The reason F-Droid builds from source is to ensure that they can enforce their inclusion criteria. If you go outside F-Droid you lose that guarantee. For example, self-published apks in github or google play may contain anti-features or proprietary code that are forbidden by the F-Droid standards.
From another point of view, what you call a single point of failure is a third party that represents the interests of the user community, independent from individual developers. This is the same model used in GNU/Linux distributions, and Drew DeVault explains here the role that software distributions play in the free software community.
Of course, this represents a trade-off, in that you are placing trust in the software distribution instead of or in addition to the upstream developer. The question is, how can you solve the problem without foregoing F-Droid’s inclusion standards? The answer is reproducible builds, where F-Droid builds from source and compares to the developer’s apk, and publishes the developer’s apk with their signature if the build reproduces successfully.
Until Reproducible builds are the norm in the Android free software world, I accept the trade-off because I value having software freedom in my computing, and I know I can’t trust upstream developers to care about that as much as F-Droid or I do.
Sure, atleast you admit there’s a trade off (security) for (FOSS) and maybe some additional privacy.
People should be made aware of the risks and choose according to their threat models, which is why I’ve highlighted some of these issues to begin with.
Everything the F-droid team does is out in the open. Your welcome to audit it once in a while and suggest changes to make it better. I’m sure they wouldn’t mind the help.
F-droid is the best tool we got. Its not a silver bullet but it is better than anything else I’ve seen