Eirikr70 Wouldn't Obtanium be essentially worse than f-droid in this case? Since Obtainium doesn't check signatures at all (you need to use AppVerifier)

    TalentedQuill No, neither F-Droid nor Obtainium really "check" signatures.
    AppVerifier is "required" in both cases, if you care about the app being signed by the original developers - barely relevant with F-Droid, as they mostly sign themselves, a bad practice.
    Android does check for the signature if you update an app, but only does to check if it is the same signer as the previous app had.

    In this case it doesn't matter if you install with a F-Droid client or Obtainium. The issue lies with the F-Droid Repository itself, or rather their toolchain (not commenting on whether it's easy to exploit or not).

    Obtainium does "solve" the issue by making you get the original APK from the developers, which most likely aren't using F-Droids tools, so you aren't relying on F-Droids infrastructure/toolchain which is affected by this current issue.

      Just because there is an open vulnerability, you cannot just say "look here, F-Droid bad!"

      it depends on how they respond to this and how long it takes to patch it.

      I also hope the author has privately disclosed that issue to F-Droid instead of immediately bragging about it on Github... harm reduction and stuff.

      It looks like they have disclosed the issue some time ago with no reaction. Lets see.

        Fupira exactly this. Not to mention, they also had a leaky configuration which, quote:

        In specific situations, the old setup was leaking the private deploy key which granted access to directly push commits to fdroiddata. We immediately revoked that key, then removed all privileges from the @fdroidci user that was associated with that private key. We also investigated all the leads we could follow to see if someone had used this key to insert something into F-Droid. We searched the activity of the @fdroidci user and found no evidence that unauthorized commits were added.

        leads me to believe that the whole F-Droid project is now maintained by sheer incompetence. These guys must have learned from the industry leaders like Cisco, Palo Alto and Fortinet. Then the audacity to state this:

        Working in public means everyone is free to investigate and come to their own conclusions, and contribute to a more secure free software ecosystem on Android.

        at the bottom of that same page is a slap in the face of everyone who tried to tell them what to do to fix their dozen security related issues. My conclusion is, they will never change. @akc3n's post has been online for 3 years now. No improvements over 3 years. Bonkers.

        K8y Aurora has its fair share of issues too, when compared to the Play Store itself. However, it is nowhere near the catastrophe F-Droid is, because they don't have repos, which eliminates a good chunk of problems from the get-go.

        Fupira AppVerifier is "required" in both cases

        Yeah, but AppVerifier isn't updating their database as far as I can tell. Most apps I download via Obtanium don't verify. I have to take the extra steps of using apksigner or hunting for the .RSA file in the apk just to get a shasum to use with Appverifier and even then not all verify. Hardly any devs post GPG keys or shasums anywhere let alone on 2nd or 3rd web sources. Chain of trust here is a shit show. Even though I only have like 3 apps in F-Droid now I still respect them for trying to do something about it over a long time period. It is easy to take shots at FDroid but they are the ones attempting heaving lifting with chain of trust. Would be nice if Appverifier and Accrescent would pick up the pace. If I had the required technical skills this is where I would contribute.

          missing-root It's worth nothing that Obfusk is not some random security researcher. They're an ex F-Droid member that left the team a few months back, and if I remember correctly, one of the reasons why they left is because issues like these were routinely ignored and working with the main person who makes the decisions at F-Droid was too difficult.

          People feel the need to jump at every opportunity to defend F-Droid because they might believe in their mission and are therefore willing to "forgive" mistakes, vulnerabilities etc., but I don't think that people would extend the same courtesy to GrapheneOS if there was a vulnerability, and we fixed it in a way that caused further vulnerabilities despite being told so.

          Food for thought.

          As a general note, I would like to ask people here to keep it classy and about the vulnerabilities in question. I felt I needed to provide some context because it seemed like people lacked context about who the person disclosing these vulnerabilities is.

            matchboxbananasynergy changed the title to F-Droid vulnerability allows bypassing certificate pinning .

            One more note: I have edited the title of this post to be more descriptive and matter-of-fact rather than sensationalist. I'm hoping that the posts in this thread will reflect that direction.

            matchboxbananasynergy keep it classy

            Apologies if my response seemed intense. Not intended.

            The stark truth is that people learn how to install, GOS, the most secure mobile OS in the world and then hit a wall when starting to install apps. I've been on GOS for 5 years across several phones as an amateur. The entire time it has been Github Dev crowd poking at FDroid and FDroid supporters poking back.

            It makes no sense that this has gone on this long. Much appreciated that the GrapheneOS team has endorsed Accrescent. It is just frustrating that this kind of effort took this long and is moving so slowly.

            As near as I can tell, Accrescent, Appverifier are nearly solo projects just like Divest which has ended. Are they sustainable?

            Great that a credible researcher has found an issue. However, will chain of trust be solved any time soon or will there just be endless poking at each other?

            Could more people with skills actually help out?

              sky9000 it's not poking for no reason. They seemingly have a systematic issue with their security architecture which needs fixing, but hasn't been addressed for years (see my response above). Every passing day something new comes up, something where you can only shake your head in disbelief. I wholeheartedly agree that there should be a trusted app store, however; the only people seemingly capable of such a feat are drowning in work.
              I was a big proponent of F-Droid until I did my research and found the gaping holes that plague it to this day. Now I recommend people to use different clients and disable their repo. And this wouldn't be the case if they just FINALLY fixed their problems!

              missing-root F-Droid has had major unaddressed security issues for years which have been repeatedly raised. The development team have demonstrated an extremely anti-security attitude. They disregard basic security best practices for Android development and are highly resistant to improving it. This is one symptom of the poor security of F-Droid rather than even being one of the major issues with it. The entire approach of automatically fetching and building apps in an outdated environment on outdated, poorly maintained infrastructure which are then signed with their own keys while using the official app ids is horrible. The whole thing needs to be thrown out and replaced. They also don't follow the security model for app sources, don't support key rotation and many other issues. F-Droid causes major usability issues with profiles due to not following Android development best practices, which has put a substantial support burden on us. Steering people away from it is important to avoiding them having a bad experience using profiles due to their misuse of app ids not belonging to them.

              @sky9000

              It is easy to take shots at FDroid but they are the ones attempting heaving lifting with chain of trust.

              This is complete nonsense. They're not doing any heavy lifting and are making the situation much worse. They've introduced major usability issues and confusion by reusing app ids with their own signing keys. This does not provide a chain of trust but rather breaks it since the apps are not signed by the developers and securely provided to you but rather built on insecure server infrastructure but quite clearly untrustworthy people who do not care about security in the slightest but rather only going through the motions of pretending they do.

              The stark truth is that people learn how to install, GOS, the most secure mobile OS in the world and then hit a wall when starting to install apps.

              The main way to get Android apps is the Play Store and it works fine. A bunch of other options are available and it's not a GrapheneOS issue that those are quite fragmented.

              The entire time it has been Github Dev crowd poking at FDroid and FDroid supporters poking back.

              F-Droid is incredibly poorly designed and maintained. It's a complete security disaster. It's a usability disaster. It has never been a good option for obtaining apps and was always preventing progress in the space due to people focusing on it and not making something much better.

              F-Droid automatically downloads and builds code, so despite their false marketing it does not protect users from the developers in any real way. It often adds substantial delays for updates including security patches. Their builds have often rolled back dependency versions, signing scheme version and the SDK to much older versions with security flaws. They've consistently introduced security flaws to the apps. It adds additional trusted parties who have demonstrated a clear lack of trustworthiness including several of their core team members spreading fabricated stories and repeatedly engaging in cover ups. In what sense is this a safe way to get apps?

              It makes no sense that this has gone on this long. Much appreciated that the GrapheneOS team has endorsed Accrescent. It is just frustrating that this kind of effort took this long and is moving so slowly.

              F-Droid has massively hindered progress because it got the mind share of a lot of the open source community before people started realizing how awful it is and that it's not ever going to become a great platform. The people developing it are incapable of making good software, do not like the overall platform, do not understand it and don't truly want it to succeed. The main developer has repeatedly made statements against app sandboxing and other basic tenets of privacy and security.

              As near as I can tell, Accrescent, Appverifier are nearly solo projects just like Divest which has ended. Are they sustainable?

              What makes you assume F-Droid is sustainable? F-Droid has severe security flaws throughout their app, repository, infrastructure for building/signing apps and servers. These have been repeatedly pointed out and the remaining team has focused on covering up issues, misdirecting from it and making excuses for it. F-Droid also causes major usability issues with Android profiles due to them reusing app ids with different signing keys, which they refuse to even acknowledge is against the basic best practices for Android development. They also still publish an outdated F-Droid version on their site as the main download option, causing more usability issues and also not giving people the latest security fixes from the start.

              Great that a credible researcher has found an issue. However, will chain of trust be solved any time soon or will there just be endless poking at each other?

              If you continue to misrepresent, downplay and deny the many real issues about F-Droid, you'll no longer be participating in our community.

              Could more people with skills actually help out?

              F-Droid is the main barrier to getting well designed, secure distribution of open source and other apps fully implemented and widely adopted. It's a huge barrier to it. F-Droid is actively negligent and is putting users at risk. They've taken many anti-security positions and are against basic tenets of security. Their team has consistently attacked GrapheneOS. Helping them deters progress rather than enabling it. You portray this as if we're trying to accomplish the same thing and should be working with people involved in harassment towards our team.

              I have a question that is on-topic. Can someone explain what certificate pinning it is that can be bypassed? What is the consequences of this vulnerability for the end-user?

              I suppose F-Droid repository looks pretty much like on any Linux distribution, that is, the repository data your device retrieves is signed with a key controlled by F-Droid, and then each app mentioned there has a SHA256 of the APK file. My understanding was that F-Droid always retrieves source code releases for apps, and build apps themselves. Is it the source code archives that is signed in a way that can be bypassed? Or is there some other component here that works in a way not typical of how Linux app repositories are maintained?

              I couldn't really understand from the vulnerability description or the linked mailing list posts, so would appreciate if someone would explain.

                sky9000 Great that a credible researcher has found an issue. However, will chain of trust be solved any time soon or will there just be endless poking at each other?

                Could more people with skills actually help out?

                My impression is that there is absolutely zero agreement about how even an ideal app repository for GrapheneOS would look like. There just seem to be so many competing security goals, with no proposed solution solving them all.

                I guess the best bet to replace the use-case of F-Droid would be for a trusted party to start downloading and compiling the source code for a very large number of apps, in a secure and modern environment, and then distribute it all like a traditional signed Linux app repository. And making local patches to the source code for an app whenever it has a too low target SDK, has trackers or ads, or other security or privacy issues. This would be close to how F-Droid is run, and would give the number of apps needed for critical mass without relying on each app developer themself submitting their app to a yet mostly unknown app repository, but could take security seriously too, in how we who use F-Droid today would want security to be.

                Problem is, the amount of work to maintain an app repository, let alone one that has most modern open source apps, is a gigantic undertaking, not something a single person can really do. But if someone where to do it, I think most or all GrapheneOS users using F-Droid today as their primary or only app store would switch to it pretty much immediately.

                ryrona It looks like there are multiple issues. One of the issues looks like not properly checking signatures for imported APKs where malicious APKs can be imported and end up included in the signed metadata. As far as we're concerned, the existing major design flaws and lack of trustworthiness of people with access to their critical infrastructure including the badly maintained build / signing infrastructure are a bigger issue. The status quo of what's known about F-Droid's processes, infrastructure and team is already very scary.

                  F-Droid doesn't provide most modern open source apps in their official repository. A huge portion of the apps it does have are completely abandoned or very poorly maintained. A huge portion fail to meet important privacy and security standards which even the very lenient Play Store implements such as a target API level requirement. It's a poor way of showing off the open source app ecosystem for Android. It provides most apps which come from particular parts of the open source community, but with delayed updates and often problematic changes including introducing security vulnerabilities via downgraded dependencies.

                  It's their own builds on their own infrastructure, almost entirely with their own signing keys except the small portion they use their problematic reproducible builds system. That system locks in using a problematic legacy build environment and will result in even more significantly delayed updates due to how they set it up. They make some minor, undocumented and often quite problematic changes to strip out functionality depending on Play services, etc. They certainly don't systemically update library dependencies or anything like that. They often actually downgrade dependencies. They've consistently introduced serious vulnerabilities to apps through using legacy tools, SDK, libraries, etc.

                  Simply building a similar kind of system following security best practices, not reusing app ids, not using a bunch of legacy software but still redoing the builds like a traditional Linux distribution be far better. There are massive problems with both their approach and implementation.

                  We don't consider F-Droid to be a trustworthy source of apps at all. They consistently disregard security and actively take anti-security positions. They don't care about or follow best practices for Android or security. They put on a show with the near useless shallow audits. They fundamentally don't understand or care about it.. They also consistently engage in cover ups, misdirection and misinformation as tactics to deal with security vulnerabilities and deep security design flaws throughout the software.

                  Several F-Droid core developers supported Copperhead's 2018 takeover attempt on GrapheneOS and then supported Copperhead's attacks over the following years. They moved on to engaging in spreading fabricated stories about our team themselves with the goal of directing harassment towards us. They supported extreme harassment from others. Nothing was done about their project members baselessly calling one of our team members insane, schizophrenic, delusional, etc. across a bunch of chat rooms and elsewhere. They made up fabricated stories about that too. It reflects on the lack of character of the overall F-Droid team. Why should GrapheneOS users trust people engaging in such underhanded tactics with the critical role of building and signing most of their apps? It's never something our community is going to broadly support even aside from the technical issues. Technical issues could theoretically be fixed (although there's no sign of much changing) but it's still not going to be run by trustworthy people.

                    GrapheneOS Why should GrapheneOS users trust people engaging in such underhanded tactics with the critical role of building and signing most of their apps?

                    Probably because they didn't (don't) know (better).
                    I know I didn't. Especially what was written here is so informative. Thanks :)
                    I uninstalled the F-Droid Client the other day off my Pixel because of this article:
                    https://privsec.dev/posts/android/f-droid-security-issues/
                    And just now off my girlfriends Pixel.
                    The apps where replaced with APKs directly from the dev.
                    No point, for me, in running GrapheneOS because of its enhanced security and then introducing a risk over F-Droid.
                    I didn't have many apps from them anyway (Mullvad and IVPN).
                    Only to avoid the PlayStore.
                    Just looking into Obtainium and Accrescenct and AppVeryfier.
                    Thanks guys, always a pleasure to educate oneself here and implement then at home :)

                    DeletedUser87

                    Pretty amazing work in that GitHub repo full credit to what appears a Security Researcher or Consultant doing it.