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

Clean up wording

Signed-off-by: Friendly Rabbit <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
Friendly Rabbit 2024-07-08 19:25:39 -07:00
parent d162483edb
commit 2d708bf800

View File

@ -51,11 +51,11 @@ Huawei AppGallery seems to have a [similar approach](https://developer.huawei.co
## 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.
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-Droids 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.
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-Droids 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 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'".
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'".
## 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)).