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.
Those are some very strange objections to F-Droid. The outdated signing software on the backend doesn’t really affect the end user, for a start. The signing key problem is also present in Google Play, the only other app store people actually use, and it’s intentional.
F-Droid builds the sources developers make available, it doesn’t accept a developers 's build with the pinky promise that no malware was added when they compiled there code.
The loose requirements are a feature, not a bug; things like a low API target level are why Termux still works on F-Droid but not on GPlay. This does pose some privacy risks because of API compatibility stuff, but because of the requirements for an app to be even listed on there, the impact is minimal.
Should F-Droid improve their technical debt? Definitely. Does any of this pose an actual risk to users? Definitely not.
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…
I don’t see how supply chain attacks on F-Droid are any different from other app stores. Supply chain attacks would also attack the APK compiled on a deb’s machine.
Also, APKs are signed on Google’s servers, devs don’t have control over those signatures anymore, unless they distribute their APKs through other means (which would impose similar if not worse risks compared to F-Droid, of course).
Those are some very strange objections to F-Droid. The outdated signing software on the backend doesn’t really affect the end user, for a start. The signing key problem is also present in Google Play, the only other app store people actually use, and it’s intentional.
F-Droid builds the sources developers make available, it doesn’t accept a developers 's build with the pinky promise that no malware was added when they compiled there code.
The loose requirements are a feature, not a bug; things like a low API target level are why Termux still works on F-Droid but not on GPlay. This does pose some privacy risks because of API compatibility stuff, but because of the requirements for an app to be even listed on there, the impact is minimal.
Should F-Droid improve their technical debt? Definitely. Does any of this pose an actual risk to users? Definitely not.
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?
deleted by creator
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…
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 don’t see how supply chain attacks on F-Droid are any different from other app stores. Supply chain attacks would also attack the APK compiled on a deb’s machine.
Also, APKs are signed on Google’s servers, devs don’t have control over those signatures anymore, unless they distribute their APKs through other means (which would impose similar if not worse risks compared to F-Droid, of course).
If you think Fdroid security is on par with Google security… then I got a bridge to sell you