How to explain why Accrescent over F-Droid?

Scott

GrapheneOS leo F-Droid's repository metadata is poorly designed and the security is poor. The security of anything built around an ecosystem of insecure scripts, clients, builds, etc. is highly questionable.

I donated to both GOS and F-Droid the same day. This was an error from me? They can use my donation to improve security?

DeletedUser24

Scott

hey can use my donation to improve security?

Security isn't bad because of a lack of resources, it's mainly an ideological issue.
They consider that what is generally defined as good security practice only applies to closed-source proprietary, and that open-source services don't need it.
There's a complete disinterest about security.

[deleted]

Scott If i were you, id double the amount for GrapheneOS and forget about donating to to F-Droid.

Scott

DeletedUser24 Security isn't bad because of a lack of resources, it's mainly an ideological issue.

I may really be a bit stupid. But I still haven't understood why F-Droid security is so bad. They do the same thing as Debian, just for Android. Can you explain it simply?

missing-root

Murcielago yeah that doesnt work

matchboxbananasynergy

missing-root Obtainium absolutely does automatic updates. If you're getting apps with a low targetSdk, then the unattended API won't work for them, but Obtainium updates apps for me all the time.

missing-root

matchboxbananasynergy strange. The low SDK apps are where I need to press on the "update" android package manager popup manually, right?

I am not talking about that, it doesnt work on its own, in the background.

It even tells me that Obtainium needs to be in the foreground to do that, which is not the definition of automatic updates

matchboxbananasynergy

missing-root Perhaps you can talk to Obtainium's developer for more info, or maybe they have docs up. I remember getting automatic updates to work for Obtainium was an ordeal due to the app being written in Flutter, but it's been done for a while.

For me, without touching Obtainium, I get a notification telling me "AppName may have been updated to version 0.0.1" or something similar. The may have been updated bit in the notification is there for a reason, but I forget the details.

de0u

Scott I still haven't understood why F-Droid security is so bad. They do the same thing as Debian, just for Android. Can you explain it simply?

As was recently discussed, Debian is not at the top of the heap in terms of security. So "Debian does X" does not imply "X is fine". That is the simple version.

Debian is ok at desktop Linux security. But desktop Linux security is distinctly not great. However, because security is complicated, the reasons why desktop Linux security is not top-shelf are not reasons that can be stated in a few words. So asking for a simple explanation is asking for something that is not feasible.

Here is some non-simple material about security of desktop machines in general (even before the question arises of which desktop OS is run): https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation/36

Overall, "Debian does X" does not imply "X is fine".

leo

Scott I still haven't understood why F-Droid security is so bad. They do the same thing as Debian, just for Android. Can you explain it simply?

To understand why F-Droid security is considered bad, one should keep in mind the Android OS security model. With regards to installing apps, the Android OS security model assumes two things:

Trust in the app author, materialized as a cryptographic signature in the APK. The OS will block an app update if it is not signed with the author's signature.
Trust in the app store, materialized as a permission that needs to be granted to each app store. The OS will block an app install if it the app store installing it does not have this permission.

With this in mind, F-Droid is considered to have bad security because:

It breaks the trust in app authors. 91% of the apps distributed by F-Droid are built and signed with a signature managed by F-Droid instead of the app author. This means that F-Droid could change what these app contain without the knowledge or consent of their author. This does not concern the 9% of apps that are reproducible by F-Droid, and therefore signed by their author. (Note that the Google Play Store also breaks trust in app authors: apps are now required to let Google manage their signature in order to be published on Google Play.)
It breaks the trust in app stores. F-Droid allows users to install apps from additional repositories using the F-Droid client. This means that users could add repositories that distribute apps that are not curated by F-Droid and therefore potentially unsafe using the same app store, without the Android OS asking to grant a permission for it. This can be avoided by using a client that only connects to a single repository, such as the unofficial G-Droid and IzzyOnDroid clients.
"F-Droid's repository metadata is poorly designed". I am not sure what this specifically refers to, but if it is true, it means that clients connecting to F-Droid repositories cannot be trusted when installing apps. This can be solved by manually verifying that those apps are signed by their author before the first install, using for example AppVerifier.
"the security is poor." I am also not sure what part of the F-Droid security model this refers to. It could be the fact that when an update is published by an app author, it can take up to a week to appear on the official F-Droid repository.
"an ideological issue". Perhaps this refers to the way the F-Droid team treated an issue that was reported on the Open Source Security mailing list. From my limited understanding, this issue ended up being solved without impacting anybody, but I may be wrong.

As you can see, the situation is not at all black and white. Whether F-Droid is really secure for you mainly depends on your threat model. However, given that most users do not know about these intricacies, I understand why it is commonly recommended to not use F-Droid.

« Previous Page