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.

unless the Accrescent client was also compromised to remove app signing key pinning

No, the OS package manager is what implements the baseline pinning and downgrade protection. That's why having an app repository like F-Droid with poorly secured builds and keys by untrustworthy people is such a terrible idea. It means even already installed apps can be compromised.

      GrapheneOS F-Droid's repository metadata is poorly designed and the security is poor.

      Thanks, I didn't know about this.

      unless the Accrescent client was also compromised to remove app signing key pinning

      No, the OS package manager is what implements the baseline pinning and downgrade protection.

      Sorry for my ambiguous message. I was referring to the fact that the Accrescent client verifies an app's signature even before the first install, compared to baseline pinning from the Android OS which only verifies an app's signature during app updates. If I understand this correctly, this prevents a scenario where a compromised Accrescent server could deliver malicious apps to people who are installing them for the first time with the Accrescent client. A malicious actor would therefore need to compromise the Accrescent client as well. Again, please correct me if I'm wrong, I am not at all an expert in this topic.

      By the way, thanks a lot for making GrapheneOS and staying in touch with the community. I learnt a lot from the beautiful GrapheneOS documentation and from your posts on the forum!

        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?

            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]

                • Post #26

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

                  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

                      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.

                        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?

                            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".

                              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:

                              1. 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.)

                              2. 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.

                              3. "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.

                              4. "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.

                              5. "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.

                                  9 months later

                                  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.

                                  leo, considering users being able to add multiple repositories to their client of choice a security vulnerability is, to me, an ideological stance. That's akin to staying that a user shouldn't be able to install a different application store due because it might harbour vulnerable or malicious software.

                                  Flatpak permits it, and nobody considers it to be a vulnerability. At a reasonable point, when forewarned, a user must be responsible for some of their security where the sole method of reducing that vulnerability would include reducing their freedom.