x0rg
/
9x0rg.com
1
0
Fork 0
Code Releases Activity

typos, formatting

This commit is contained in:
Wonderfall 2022-01-03 05:55:41 +01:00
parent 5bd77c8d8d
commit 15a7cc365b
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
content/posts/fdroid-issues.md
View File

@ -25,7 +25,7 @@ F-Droid also requires that the source code of the app is exempt from any proprie
## 2. Slow and irregular updates ## 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 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). 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 do F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, they also have a rather strange way of triggering new builds. Part of their 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 system** (meaning it's disconnected from any network), 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 singing keys to one party, you could also introduce a single point of failure. Should their system be compromised, it could lead to serious security issues affecting plenty of users. Not only do F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, they also have a rather strange way of triggering new builds. Part of their 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 system** (meaning it's disconnected from any network), 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, it could lead to serious security issues affecting plenty of users.
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. 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.
@ -56,14 +56,14 @@ F-Droid also **doesn't enforce a minimum target SDK** for the official repositor
## 4. 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 of the F-Droid users will 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. As a matter of fact, the new unattended update API from Android 12 that allows seamless updates for third-party clients without privileged access to the system won't work with F-Droid. 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 of the F-Droid users will 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. As a matter of fact, the new unattended update API from Android 12 that allows seamless updates for third-party clients without privileged access to the system won't work with F-Droid.
Their client also lacks **TLS certificate pinning**, unlike Play Store. Certificate pinning is a way for apps to increase the security of their connection to services by bundling known-good certificates for these services. This can avoid some cases where an interception (man-in-the-middle) could be possible and lead to various security issues considering you're trusting the app to deliver you other apps. Their client also lacks **TLS certificate pinning**, unlike Play Store. Certificate pinning is a way for apps to increase the security of their connection to services by bundling known-good certificates for these services. This can avoid some cases where an interception (*man-in-the-middle*) could be possible and lead to various security issues considering you're trusting the app to deliver you other apps.
F-Droid also has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)** as 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. Quite frankly, this is straight-up bad. F-Droid also has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)** as 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. Quite frankly, this is straight-up bad.
## Conclusion: what should you do? ## Conclusion: what should you do?
F-Droid **weakens the security model of Android substantially** for all of the reasons above. If security matters to you, it should not be used. If you don't care or if you'll use it knowingly, then it's up to you. While they could make some easy improvements, I don't think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. F-Droid **weakens the security model of Android substantially** for all of the reasons above. If security matters to you, it should not be used. If you don't care or if you'll use it knowingly, then it's up to you. While they could make some easy improvements, I don't think F-Droid is in an ideal situation to solve all of these issues because some of them are **inherent flaws** in their architecture.
F-Droid is also not the only way to get and support open-source apps. Sure, it can help you in finding one that you wouldn't have known existed otherwise. Many developers also publish their FOSS apps on the **Play Store** or their website directly. Most of the time, releases are available on **GitHub**, which is great since each GitHub releases page has an atom feed. Nonetheless, I'd still recommend using **Play Store for top-notch security** as it does additional checks, and it is even perfectly usable on GrapheneOS with their [sandboxed Play services](https://grapheneos.org/usage#sandboxed-play-services) compatibility layer. F-Droid is not the only way to get and support open-source apps. Sure, it can help you in finding one that you wouldn't have known existed otherwise. Many developers also publish their FOSS apps on the **Play Store** or their website directly. Most of the time, releases are available on **GitHub**, which is great since each GitHub releases page has an atom feed. Nonetheless, I'd still recommend using **Play Store for top-notch security** as it does additional checks, and it is even perfectly usable on GrapheneOS with their [sandboxed Play services](https://grapheneos.org/usage#sandboxed-play-services) compatibility layer.
> If you don't have Play services installed, you can use [Aurora Store](https://auroraoss.com/) instead which is a Play Store client. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid (one more party to trust, lack of good practices) - it should still be better than F-Droid though. > If you don't have Play services installed, you can use [Aurora Store](https://auroraoss.com/) instead which is a Play Store client. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid (one more party to trust, lack of good practices) - it should still be better than F-Droid though.