PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00
Code

Reword paragraph about F-Droid's "quality control"

Browse Source 
Signed-off-by: Friendly Rabbit <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
Friendly Rabbit 2024-07-08 20:39:19 -07:00
parent 2d708bf800
commit bf3d044d64
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/posts/android/F-Droid Security Issues.md
View File

@ -25,11 +25,11 @@ Normally, the developer is supposed to sign their own app prior to its upload on
On the other hand, the Play Store now manages the app signing keys too. [Play App Signing](https://developer.android.com/studio/publish/app-signing#app-signing-google-play) is required for app bundles which are, in turn, required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by the [Google Cloud Key Management Service](https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf). It should be noted that the developer still has to sign their app with **an upload key** so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have [not opted in Play App Signing](https://developer.android.com/studio/publish/app-signing#opt-out) yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.
Besides, their "quality control" offers **close to no guarantees** as having access to the source code doesn't mean it can be easily reviewed. Saying the Play Store is filled with malicious apps is beyond the point: the **false sense of security** is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.
A common refrain used to argue for F-Droid is the claim that the Play Store is filled with malicious apps. Saying this is beyond the point, though, as F-Droid's "quality control" offers **close to no guarantees**. Having access to the source code doesn't mean it can be easily reviewed. As such, users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.
> But... can't I just trust F-Droid and be done with it?
[You don't have to take my word for it](https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/12): they openly admit themselves it's a [very basic process](https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/2) relying on badness enumeration (this [doesn't work](https://privsec.dev/posts/knowledge/badness-enumeration/) by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempt from trusting upstream developers; this goes for any repository.
F-Droid's **false sense of security** is a real issue. [You don't have to take my word for it](https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/12): they openly admit themselves it's a [very basic process](https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/2) relying on badness enumeration (this [doesn't work](https://privsec.dev/posts/knowledge/badness-enumeration/) by the way), which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempt from trusting upstream developers; this goes for any repository.
*A tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you're already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn't be compared to the Android platform in any way.*
@ -53,7 +53,7 @@ Huawei AppGallery seems to have a [similar approach](https://developer.huawei.co
F-Droid, to carry out its "[passion for Free and Open Source Software](https://f-droid.org/en/about/) (FOSS) on the Android platform", requires that developers adhere to a strict [inclusion policy](https://f-droid.org/en/docs/Inclusion_Policy/) for their app(s) to be hosted on the main repository. Principally, according to this policy, F-Droid requires the source code of an app to exclude any proprietary library or ad service. This stringent mandate has proven to be harmful to developers and even end users.
As a result of F-Droid's inclusion policy, usually, some developers will have to maintain a slightly different version of their codebase for their app to comply with F-Droid’s requirements. For developers, this means not only spending more time and energy, but also, in some cases, working with libraries and components that may be outdated. Sometimes, the restrictions imposed by F-Droid's inclusion policy have a knock on effect on end users as well, as demonstrated in the following case with Snikket.
As a result of F-Droid's inclusion policy, usually, some developers will have to maintain a slightly different version of their codebase for their app to comply with F-Droid’s requirements. For developers, this means not only spending more time and energy, but also, in some cases, working with libraries and components that may be outdated. Sometimes, the restrictions imposed by F-Droid's inclusion policy have a knock-on effect on end users as well, as demonstrated in the following case with Snikket.
In late 2022, the Snikket project issued a [blog post](https://snikket.org/blog/fdroid-security-warning/) that addressed the users of their app who downloaded it from F-Droid. It sought to allay any panic from users if they receive a message from F-Droid "telling them that the app [Snikket] has a vulnerability and that they 'recommend uninstalling immediately'".