From 73167f814165a3626d870bf8170fb25b99d18882 Mon Sep 17 00:00:00 2001 From: Ganwtrs Date: Sun, 21 Dec 2025 20:37:00 -0800 Subject: [PATCH 1/2] fix typo in archive index Signed-off-by: Ganwtrs --- content/posts/archive/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/archive/_index.md b/content/posts/archive/_index.md index 2b5955613..f61ef60fd 100644 --- a/content/posts/archive/_index.md +++ b/content/posts/archive/_index.md @@ -4,4 +4,4 @@ ShowReadingTime: false ShowWordCount: false --- -An archive of old articles that are longer applicable. \ No newline at end of file +An archive of old articles that are no longer applicable. From 99b80285b0b9a797b5e7cb2200929c340e1de98d Mon Sep 17 00:00:00 2001 From: Ganwtrs Date: Wed, 24 Dec 2025 10:04:58 -0800 Subject: [PATCH 2/2] Correct typos on f-droid article Signed-off-by: Ganwtrs --- .../posts/android/F-Droid Security Issues.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/posts/android/F-Droid Security Issues.md b/content/posts/android/F-Droid Security Issues.md index a33b83c16..58545644b 100644 --- a/content/posts/android/F-Droid Security Issues.md +++ b/content/posts/android/F-Droid Security Issues.md @@ -45,7 +45,7 @@ Google's approach is [code transparency for app bundles](https://developer.andro [To my current knowledge](https://developer.amazon.com/docs/app-submission/understanding-submission.html#code_wrapper), the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs. -If you understood correctly the information above, Google can't do this for apps that haven't opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn't do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won't do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles. +If you correctly understood the information above, Google can't do this for apps that haven't opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn't do that without telling about it since this will be easily noticeable by the developer and external researchers. They have other means on the Android app development platform to do so. Believing they won't do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles. Huawei AppGallery seems to have a [similar approach](https://developer.huawei.com/consumer/en/doc/distribution/app/20210812) to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei. @@ -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. 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 usually 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 usually have to maintain a slightly different version of their codebase for their app to comply with F-Droid’s requirements. For developers, this not only means spending more time and energy, but it also means that in some cases, they have to work 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 December 2022, the Snikket project published 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 [subsequent 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). @@ -64,7 +64,7 @@ Overall, this case study highlights how F-Droid's inclusion policy ultimately ha ## 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 the app: it's a common thing 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). -Not only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be [automated](https://f-droid.org/en/docs/FAQ_-_App_Developers/), which is the least you could expect. Now here's the thing: app signing keys are on an **air-gapped server** (meaning it's disconnected from any network, at least that's what they claim: see [their recommendations](https://f-droid.org/docs/Building_a_Signing_Server/) for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it's the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users. +Not only does F-Droid require specific changes for the app to comply with its inclusion policy (which often leads to more maintenance work), it also has a rather strange way of triggering new builds. Part of its build process seems to be [automated](https://f-droid.org/en/docs/FAQ_-_App_Developers/), which is the least you could expect. Now here's the thing: app signing keys are on an **air-gapped server** (meaning it's disconnected from any network, at least that's what they claim: see [their recommendations](https://f-droid.org/docs/Building_a_Signing_Server/) for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it's the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users. *This is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While [this GitHub issue](https://github.com/signalapp/Signal-Android/issues/127) is quite old, many points still hold true today.* @@ -90,14 +90,14 @@ allow untrusted_app_25 proc_tty_drivers:file r_file_perms; This is a mere sample of the [SELinux exceptions](https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-12.0.0_r21/private) that have to be made on older API levels so that you can understand why it matters. -It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L42)** (Android 7.1) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients like [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). While these clients might be technically better, they’re [missing features](https://infosec.exchange/@divested/111174351060422166), pooly maintained, and they also introduce yet another party to the mix. +It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L42)** (Android 7.1) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients like [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). While these clients might be technically better, they’re [missing features](https://infosec.exchange/@divested/111174351060422166), poorly maintained, and they also introduce yet another party to the mix. Furthermore, F-Droid **doesn't enforce a minimum target SDK** for the official repository. Play Store [does that quite aggressively](https://developer.android.com/google/play/requirements/target-sdk) for new apps and app updates: - Since August 2021, Play Store requires new apps to target at least API level 30. - Since November 2021, existing apps must at least target API level 30 for updates to be submitted. -While it may seem bothersome, it's a necessity to keep the **app ecosystem modern and healthy**. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 Ice Cream Sandwich. Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support. +While it may seem bothersome, it's a necessity to keep the **app ecosystem modern and healthy**. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backwards compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 Ice Cream Sandwich. Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support. There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) along with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. The app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for the application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths. @@ -171,7 +171,7 @@ In modern Android, the background restriction toggle is what really provides the Another example to illustrate the shortcomings of this approach would be the `QUERY_ALL_PACKAGES` low-level permission, which is referred to as the *query all packages* permission that "allows an app to see all installed packages". While this is somewhat correct, this can also be misleading: apps do not need `QUERY_ALL_PACKAGES` to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default [since Android 11](https://developer.android.com/training/package-visibility)). If an app needs more visibility, it will declare a `` element in its manifest file: in other words, `QUERY_ALL_PACKAGES` is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend. -Play Store for instance conveys the permissions in a way less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by taping "About this app" then "App permissions - See more" at the bottom of the page. Play Store will tell the app may request access to the following permissions: this kind of wording is more important than it seems. *Update: since July 2022, Play Store doesn't offer a way to display low-level permissions anymore.* +Play Store, for instance, conveys the permissions in a way less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by taping "About this app" then "App permissions - See more" at the bottom of the page. Play Store will tell the app may request access to the following permissions: this kind of wording is more important than it seems. *Update: since July 2022, Play Store doesn't offer a way to display low-level permissions anymore.* Moreover, [Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE` which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place... @@ -190,7 +190,7 @@ apksigner verify --print-certs --verbose myCoolApp.apk Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature check for app updates. In practice, this means the source doesn't matter as much after the initial installation. -For most people, I'd recommend just **sticking with Play Store**. Play Store isn't quite flawless, but emphasises the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard. +For most people, I'd recommend just **sticking with Play Store**. Play Store isn't quite flawless, but it emphasizes the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard. *Note: this article obviously can't address all the flaws related to Play Store itself. Again, the main topic of this article is about F-Droid and should not be seen as an exhaustive comparison between different app repositories.* @@ -220,7 +220,7 @@ Some people tend to exaggerate the importance of Google in their threat model, a **Play Store evidently has some privacy issues** given it's a proprietary service which requires an account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the [Play services compatibility layer from GrapheneOS](https://grapheneos.org/usage#sandboxed-google-play) which runs Play services and Play Store in the regular app sandbox (the `untrusted_app` domain). This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent). -If you don't have Play services installed, you can use a third-party Play Store client called **[Aurora Store](https://auroraoss.com/)**. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid. Aurora Store somehow still requires [the legacy storage permission](https://gitlab.com/AuroraOSS/AuroraStore/-/blob/26f5d4fd558263a89baee4c3cbe1d220913da104/app/src/main/AndroidManifest.xml#L28-32), has been known to sometimes retrieve wrong versions of apps, and [distributed account tokens](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/722) over [cleartext HTTP](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/734) until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I'd recommend against using the shared "anonymous" accounts feature: you should make your own throwaway account with minimal information. +If you don't have Play services installed, you can use a third-party Play Store client called **[Aurora Store](https://auroraoss.com/)**. Aurora Store has some issues of its own, and in fact, some of them overlap with F-Droid. Aurora Store somehow still requires [the legacy storage permission](https://gitlab.com/AuroraOSS/AuroraStore/-/blob/26f5d4fd558263a89baee4c3cbe1d220913da104/app/src/main/AndroidManifest.xml#L28-32), has been known to sometimes retrieve wrong versions of apps, and [distributed account tokens](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/722) over [cleartext HTTP](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/734) until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I'd recommend against using the shared "anonymous" accounts feature: you should make your own throwaway account with minimal information. ### Looking to the future @@ -232,8 +232,8 @@ It's also worth keeping an eye on the great work **GrapheneOS** does on [their f ## Meta -This article aims to be **purely technical**. It is not an attack on F-Droid or their mission --- it is meant as an informative piece for end users and a springboard for improvement of the F-Droid project. +This article aims to be **purely technical**. It is not an attack on F-Droid or their mission —it is meant as an informative piece for end users and a springboard for improvement of the F-Droid project. -In spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers that do not share their views; hopefully they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone's best interest. +In spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who have taken a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals have go as far as engaging in harassment campaigns against projects and security researchers who do not share their views; hopefully they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone's best interest. Some individuals have also falsely associated this article with GrapheneOS. _This article is an entirely independent work and unrelated to the GrapheneOS project. It was not written by a GrapheneOS developer and does not claim to represent the GrapheneOS project's official stance._ Either way, dismissing the article on the basis of association instead of addressing the actual technical content is silly and not helpful to anyone.