Sbpr

As far as I can tell, after the 1.20 redesign of the F-Droid client, the only functional difference between Accrescent and a custom F-Droid repo may be the app signing key pinning by Accrescent, although it might not matter to you depending on your threat model.

https://x.com/GrapheneOS/status/1803185925112934533

F-Droid has far too many security and trust issues for us to recommend it. The vast majority of apps in the official F-Droid repository are built on their sketchy infrastructure and signed with their own keys. We're concerned about a future mass compromise of F-Droid users.

    fid02

    Yeah, 91% of the apps in the main F-Droid repository don't have reproducible builds, and are signed by F-Droid keys instead of the app developer's keys. This means that somebody with access to the F-Droid infrastructure could update these apps with malicious code without the developers and users noticing.

    Sbpr What about izzyondroid and Obtainium?

    Like Accrescent, the IzzyOnDroid F-Droid repo distributes builds directly from developers. The repo also implements app signing key pinning and other security measures. If I'm not mistaken, this makes using the IzzyOnDroid repo equally secure as using Accrescent (please correct me if I'm wrong).

    Obtainium is not a repo per se, although they have started a crowdsourced list of app configurations in the last months. Apart from apps in that list, apps installed via Obtainium are not curated (they are not scanned for malware, etc.). If your threat model considers developers compromising their own apps as a threat, that makes Obtainium less secure than Accrescent, and less secure than the F-Droid official and IzzyOnDroid repositories. However, if your threat model considers compromised F-Droid repos as a higher threat, it would be more secure for you to install an app via Obtainium. Accrescent would in theory resist a compromised repo, unless the Accrescent client was also compromised to remove app signing key pinning.

      missing-root

      If I'm not mistaken, there is an option for background updates in Obtainium.

      It can be activated in the app under settings> Enable Background Updates. Background Update Checking Interval can be set with the slider above. Unfortunately this doesn't seem to work with all apps.

        oxidant8751 that both F-droid and Aurora Store are insecure due to a variety of reasons

        When reading F-droid articles you should always pay attention to what is meant. Mostly the F-Droid app and F-Droid main archive.¹ There are many F-droid clients that are better. & in each client you can use the repositories you want.
        E.g. Molly, SimpleX, Cake Wallet, Monerujo, Tor (Browser, Orbot)

        ¹There have been many improvements in the last few months.

          AlphaElwedritsch We're not going to be switching to using it from our own App Store. It's included to provide a way to get developer builds of apps for developers submitting their apps to Accrescent. We don't plan to provide the same service to app developers since Accrescent has it covered and multiple options would be counterproductive.

          boldsuck

          ¹There have been many improvements in the last few months.

          There have also been continued regressions in security and trust.

          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!

            • Edited

            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.

                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.

                  • [deleted]

                  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.

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

                      • Edited

                      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.