Add Snikket case to post (WIP)

Signed-off-by: Friendly Rabbit <169707731+friendly-rabbit-35@users.noreply.github.com>

content/posts/android/F-Droid Security Issues.md

@@ -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.
 
-F-Droid requires the source code of an app to exclude any proprietary library or ad service, according to their [inclusion policy](https://f-droid.org/en/docs/Inclusion_Policy/). Usually, that means that some developers will have to maintain a slightly different version of their codebase for their app to comply with F-Droid's requirements. 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.
+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.
 
 > But... can't I just trust F-Droid and be done with it?
 
@@ -49,8 +49,16 @@ If you understood correctly the information above, Google can't do this for apps
 
 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 re-signed by Huawei.
 
-## 2. 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).
+## 2. F-Droid's ridiculous inclusion policy and its consequences
+
+F-Droid, to carry out its "[passion](https://f-droid.org/en/about/) for Free and Open Source Software (FOSS) on the Android platform", requires that developers adhere to a strict inclusion policy for their app(s) to be hosted on its 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 will have to maintain a slightly different version of their codebase for their app to comply with F-Droid’s requirements. Not only does this translates to more time and energy spent on the part of the developer, but, in some cases, it means 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 assuage those users to not panic if they receive a message from F-Droid "telling them that the app has a vulnerability and that they 'recommend uninstalling immediately'".
+
+## 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)).
 
 F-Droid not only requires specific changes for an app to comply with its inclusion policy, which often leads to more maintenance work for app developers, but 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). This setup forces an irregular update cycle where a human has to manually trigger the signing process, which is far from ideal. 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.
 
@@ -58,12 +66,12 @@ F-Droid not only requires specific changes for an app to comply with its inclusi
 
 Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect **far slower updates** compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should've been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. However, they aren't ideal either as you will see in the next section.
 
-## 3. General lack of good practices
+## 4. General lack of good practices
 The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most F-Droid users use anyway. However, having **other repositories in a single app also violates the security model of Android** which was not designed for this at all. The OS expects you to trust **an app repository as a single source** of apps, yet F-Droid violates this model as it mixes several repositories in one single app by design. This is important because the OS management APIs and features (e.g., [UserManager](https://developer.android.com/reference/android/os/UserManager), which can be used to prevent a user from installing third-party apps) are not meant for this and see F-Droid as a single source. You're trusting the app client to not mess up far more than you should, especially when the **privileged extension** comes into the picture.
 
 There is indeed a serious security issue with the OS first-party source feature being misused, as the privileged extension makes use of the `INSTALL_PACKAGES` [API](https://developer.android.com/reference/android/Manifest.permission#INSTALL_PACKAGES) in an insecure manner (i.e., not implementing it with the appropriate security checks). The privileged extension accepts any request from F-Droid, which again suffers from various bugs and security issues and allows user-defined repositories by design. A lot can go wrong, and bypassing security checks for powerful APIs should definitely not be taken lightly.
 
-On that note, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29. *Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates on Android 12 or later, but the issues with the privileged extension when installing apps through F-Droid remain.*
+On that note, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the third-party client [Droid-ify](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29. *Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates on Android 12 or later, but the issues with the privileged extension when installing apps through F-Droid remain.*
 
 It is also worth noting that the repository metadata format for F-Droid isn't properly signed as it lacks whole-file signing and key rotation. [Their index v1](https://f-droid.org/2021/02/05/apis-for-all-the-things.html#the-repo-index) format [uses JAR signing](https://gitlab.com/fdroid/fdroidserver/-/blob/d70e5c2cd92eb1924caf51a1f88202749956038f/fdroidserver/signindex.py#L40) with `jarsigner`, which has serious security flaws. F-Droid added their [index v2](https://f-droid.org/docs/All_our_APIs/#the-repo-index) format with [support for `apksigner`](https://gitlab.com/fdroid/fdroidserver/-/commit/3182b77d180b2313f4fdb101af96c035380abfd7#e915676f3ed7e51adef7ee3d1eaa0ef7be386a84) in May 2022, but this just seems to be an over-engineered and flawed approach since better suited tools such as `signify` could be used to sign the metadata JSON.
 
@@ -96,7 +104,7 @@ To be fair, the F-Droid team has considered several times about adding certifica
 
 Furthermore, F-Droid has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)**. They [held out on the v1 signature scheme](https://forum.f-droid.org/t/why-f-droid-is-still-using-apk-signature-scheme-v1/10602) (which was [horrible](https://www.xda-developers.com/janus-vulnerability-android-apps/) and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0, v3 in Android 9). Quite frankly, this is straight-up bad, and **signing APKs with GPG** is no better, considering [how bad PGP and its reference implementation GPG are](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) (even Debian [is trying to move away from it](https://wiki.debian.org/Teams/Apt/Spec/AptSign)). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.
 
-## 4. Low target API level (SDK) for client & apps
+## 5. Low target API level (SDK) for client & apps
 SDK stands for *Software Development Kit* and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you'll be able to make use of modern API levels of which each iteration brings **security and privacy improvements**. For instance, API level 31 makes use of improvements on Android 12.
 
 As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox, as opposed to outdated apps compiled with older API levels, which have a **weaker sandbox**.
@@ -135,19 +143,19 @@ At the time of writing:
 
 *Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.*
 
-## 5. Confusing UX
+## 6. Confusing UX
 It is worth mentioning that the F-Droid website has, for some reason, always been hosting an [outdated APK of F-Droid](https://forum.f-droid.org/t/why-does-the-f-droid-website-nearly-always-host-an-outdated-f-droid-apk/6234). This is still the case today, which leads many users to wonder why they can't install F-Droid on a secondary user profile (due to the downgrade prevention enforced by Android). "Stability" seems to be the main reason mentioned on their part, which doesn't make sense. Either your version isn't ready to land in a stable channel, or it is and new users should be able to access it easily.
 
 F-Droid should enforce the approach of prefixing the package name of their alternate builds with `org.f-droid` for instance (or add a `.fdroid` suffix as some already have). Building and signing while **reusing the package name** ([application ID](https://developer.android.com/studio/build/configure-app-module)) is bad practice as it causes **signature verification errors** when users try to update or install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.
 
 This results in a confusing user experience where it's hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.
 
-## 6. Misleading permissions approach
+## 7. Misleading permissions approach
 F-Droid shows a list of the [low-level permissions](https://developer.android.com/reference/android/Manifest.permission) for each app. These low-level permissions are usually grouped in the standard, high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it's often a **misleading** and inaccurate approach for the end user. Since Android 6, apps have to [request the standard permissions at runtime](https://developer.android.com/guide/topics/permissions/overview#runtime) and do not get them simply by being installed, so showing all the "under the hood" permissions without proper context is not useful and makes the permission model unnecessarily confusing.
 
 F-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have [install-time permissions](https://source.android.com/devices/tech/config/runtime_perms). Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn't run an outdated version of Android that has not received security updates for years.
 
-A [discussion about this](https://gitlab.com/fdroid/fdroid-website/-/merge_requests/834) took place on F-Droid's GitLab repository. In short, F-Droid downplayed the issue with their misleading permission labels, and their lead developer proceeded to call the Android permission model a "dumpster fire" and claim that the operating system cannot sandbox untrusted apps while still remaining useful.
+A [discussion about this](https://gitlab.com/fdroid/fdroid-website/-/merge_requests/834) took place on F-Droid's GitLab repository. In short, F-Droid downplayed the issue with their misleading permission labels, and their lead developer [proceeded](https://gitlab.com/fdroid/fdroid-website/-/merge_requests/834#note_1026963506) to call the Android permission model a "dumpster fire" and claim that the operating system cannot sandbox untrusted apps while still remaining useful.
 
 *To clear up any confusion, even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android; instead, these apps display a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app's `targetSdkVersion`. And even if this were the case, the OS package installer on modern Android would've been designed to show the requested permissions for those legacy apps.*