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

Finish Snikket case study

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 21:33:27 -07:00
parent bf3d044d64
commit 404f0fb96e
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -25,7 +25,7 @@ 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.
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.
A common refrain used to argue for F-Droid is the claim that the Play Store is filled with malicious apps. Saying this is beside 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?
@ -55,7 +55,11 @@ F-Droid, to carry out its "[passion for Free and Open Source Software](https://f
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'".
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 warning from F-Droid "telling them that the app [Snikket] has a vulnerability and that they 'recommend uninstalling immediately'". In a [later blog post](https://snikket.org/blog/fdroid-security-update/), Snikket clarified that this warning from F-Droid "wasn’t entirely accurate, as the problem wasn’t with the Snikket app itself but specifically *F-Droid’s own build of the app* that was using *an outdated version of the WebRTC library*" (emphasis added).
Indeed, as the first blog post by the Snikket project details, the WebRTC component of Snikket's F-Droid version pulled third-party binaries from Google's Maven repository (which stopped releasing new builds in January 2020), presumably to adhere to the parts of the inclusion policy that forbid the use of "Non-Free" dependencies and build tools. Note that the developer-signed versions of Snikket published on the Play Store were not affected by this issue, for they were built with a modern WebRTC version. Furthermore, the subsequent blog post by Snikket reveals how the older third-party version of WebRTC used by F-Droid actually hindered the addition of new improvements to the app from upstream.
Overall, this case study highlights how F-Droid's inclusion policy ultimately harms end users by forcing app developers to adopt potentially decrepit development tools and build processes in service of their regnant FOSS ideology.
## 3. Slow and irregular updates
Since you're adding one more party to the mix, that party is now responsible for delivering proper builds of an app. This is a common practice among traditional Linux distributions and their packaging system. They have to catch up with *upstream* on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive *downstream* changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it's as bad as it sounds, but that's [another topic](https://privsec.dev/posts/linux/choosing-your-desktop-linux-distribution/#release-cycle)).