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:
parent
d162483edb
commit
2d708bf800
@ -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-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.
|
||||
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 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)).
|
||||
|
Loading…
Reference in New Issue
Block a user