SovereignCopper

This is very sloppy and shouldn't have happened. Also, it was analyzed, handled and reported, leading to vast improvements to the automation system. I'm not sure I have an issue with people making mistakes as much as with people holding it against them until the end of time.

The system is still designed is an incredibly insecure way and is run by people who do not build things with security in mind or prioritize it. There is no way that it should work anything like this. It is not simply a mistake.

Vanadium ships with loads of upstream vulnerabilities that get patched all the time. I don't see people here saying the Chromium base is completely insecure and therefore we should never trust it and its devs ever again.

There's quite a difference between having memory corruption bugs in C++ code for a browser vs. designing a package repository in an incredibly insecure way. Chromium didn't really have a viable alternative to C and C++ at the time, but new software does, and Chromium should be criticized for not quickly migrating to a memory safe low-level language as Android is doing.

F-Droid doesn't ship all the available fixes for upstream vulnerabilities in the many outdated dependencies they're using and shipping to end users in app builds. They often take years to ship important updates and adopt new APIs released to address security vulnerabilities. Do you think it would be fine if Vanadium stayed on Chromium 132 for the next 2 years and started disabling upstream security features inconvenient to us along with not adopting new ones?

That's the only thing I'm wary of, although it has already been established here that the environment itself isn't EOL, just "Debian-outdated". That doesn't justify the use of older JDK's imho, though, so I agree they'd be better off using a more up-to-date distro.

They use a bunch of end-of-life tools with unpatched security vulnerabilities. Debian doesn't truly provide the kind of security support people imagine it does. Backporting a subset of the patches for issues with CVE assigned is not providing most security patches. F-Droid builds with more than an outdated JDK.

SovereignCopper

That's fair enough, but honestly? I hate that part of GrapheneOS. Every single time I update, I have to reserve some bit of "headspace" for the chance something breaks. Especially when doing automated jobs (back to the F-Droid case), these kinds of problems are quite sensitive. Now I already agreed that using Debian LTS is not a good option, but bleeding edge in such an environment, all for that 0.000000000000000000000000001% chance that someone would abuse a vulnerability in the 48 hours a package wouldn't yet be updated... then I'd say there's a decent balance to find there.

Debian takes years to ship many security patches, not 48 hours, and Debian LTS doesn't have official security support. You're operating under the incorrect belief that most security vulnerabilities get CVE assignments particularly in the kinds of projects that it's built from or that or that they actually ship those quickly. It doesn't work that way for Debian stable and certainly not LTS.

I reckon this is also where "bad blood" comes into play. I mean, the fact that "exerting public pressure" like you said is expressed in terms ranging from "Can't even get their regex right" all the way to "bulls**t behavior" and other expletives, together with the entitlement (not yours, but of others) I've read seems to make this hostile instead of constructive. That's just sad, because you're basically on the same side, while having arguments over bikeshedding.

F-Droid has an egregiously poor approach to security and has consistently engaged in cover ups, attacks on security researchers and attempts at discrediting them with fabricated stories and harassment. They're genuinely untrustworthy people who shouldn't have a highly trusted position. F-Droid doesn't simply have regular slip ups and vulnerabilities but rather an insecure architecture and approach from top to bottom where security is not and has never been prioritized. Not only that, but they do not acknowledge most of the issues and do not take serious steps to address to huge problems with the architecture. Papering over symptoms of the huge architectural issues one by one rather than designing for security is not taking it seriously. There are very few people looking into it so you can't expect to see a steady stream of vulnerability reports and it does not mean they aren't there.

Here's an example of the people involved engaging in harassment, then covering it up and subsequently fabricating stories about it they posted across many platforms:

https://archive.ph/j7qql

Why would anyone trust their cover ups of security flaws and potentially breaches in their blog posts? Why do you expect they'd admit to it and tell anyone when they've been repeatedly caught in situations like that blatantly lying about security and engaging in incredibly underhanded and dishonest attacks on security researchers in an attempt to discredit them?

elisa4501 F-Droid has no future in a privacy/security focused mobile ecosystem. The core developers do not understand the basics of security, do not care about it and have consistently proven they cannot be trusted. They should not be in control of anything important, let alone being a major single point of failure for distributing open source apps that's bound to turn out horribly. If F-Droid infrastructure gets compromised and the people using it get shipped a whole bunch of apps with malware injected, that won't be surprising in any way and no one can claim we didn't try to warn people and steer them away from it. It should end up being a way people criticize GrapheneOS as if we directed anyone towards using it. We fully expect that to happen and consider it quite a serious problem how many of our users are making use of it. The main thing holding back better alternatives if F-Droid itself and F-Droid is never going to become a secure and trustworthy source of apps. The sooner people move on and start focusing on alternatives, the sooner those will start having far more resources and apps. F-Droid is not trying to build something that fits into what we're trying to build.

    GrapheneOS The sooner people move on and start focusing on alternatives, the sooner those will start having far more resources and apps.

    Is Obtainium a decent alternative? Is it imperative in order to have proper security, to use AppVerifier along with it?

      ParanoidAndroid directly from Source: You need to trust the developer and the Source that the uploaded binary is safe

      Do keep in mind you technically have to trust the developer no matter what app source you use. As there's always a possibility of malware slipping through no matter the source. And also a benefit of getting it directly from the source yourself is if provided you are willing to do so you can take steps and precautions to manually verify it yourself. Which is quite nice as it places a factor of trust in yourself rather than putting ALL of your trust in app sources.

      Ultimately in terms of you asking guidance on how to proceed.. Well it's genuinely a matter of two things.

      1. Your threat model
      2. What you value most

      Following up from 1. As in what are you trying to protect yourself from and how severe or dangerous is the threat to you?
      Following up from 2. As in what do you value most? Security? Privacy? Overall control? Feature theatre? Minimalism? The list goes on and on of things people can value more than other things.

      Point is I wouldn't say it's necessarily dumb to keep using F-Droid if your threat model and priorities do not demand good security. It's your call. Just do always keep it's massive issues in mind if you do. That should go for any method too always keep in mind of the issues or shortcomings it has.

      I will say though in terms of mainly wanting to use FOSS software you could subscribe to F-Droid's RSS news feed! I never really see people talk about this but it's a genuinely good way to still engage with FOSS apps without having to have F-Droid installed because general F-Droid news aside it tells you about certain big noteworthy App changes, what apps got updated though I would suggest ignoring the updates part since it's been discussed several times that F-Droid lags behind pretty badly on updates. And most importantly what new apps got added! Which would be important in trying to discover new FOSS apps. And then of course you can use the F-Droid website to find quick links to the app's source to read more about it or install it from there. This method allows you to still easily engage with FOSS apps but without the necessity of having F-Droid badly compromising your security.
      Even if you use/continue to use F-Droid though I'd say the you should still use the RSS feed or check the news section of their site every now and then. It's quite informative!

        GrapheneOS
        A lot of privacy focused apps have directed us to download from FDroid - Molly, Thunderbird, Proton.It is very difficult to make a right decision from the beginning because of the lack of clarity.

        Moving away from FDroid now feels like the transition from an IPhone to GrapheneOS. Too many apps configured to work with a homelab that now all have to be redone.

          DeletedUser95

          Thanks for this detailed advice! I am still trying to get my thougts ordered about this topic. So basically for me the question is why I should use Obtainium over F-Droid..

          F-Droid's security is a point but when F-Droid builds the app it is more or less guaranteed, that the app was build from the source code. This is not the case when Obtainium is the installation-source because the signature that can be verified has nothing to do with the Code.

          If my assumption is correct I don't get why I should trust many developers when using Obtainium instead of only trusting F-Droid. Isn't the Security compromised with each app that is installed and updated via Obtainium?

            n2gwtl I have done that shift and didn't find it that hard. You mainly have to reenter your path and reidentify.

            Themble Is Obtainium a decent alternative?

            Questionable. I think the two sides of the coin has been discussed above. With Obtainium you don't put any trust in F-Droid, but on the other hand, you put all that trust in yourself instead.

            Think of using F-Droid as installing apps in Linux from the official repositories, and Obtainium as downloading exe-files from the web in Windows. Neither is necessarily better or worse for the security for someone that knows what they are doing. F-Droid seems clearly better if you don't know what you are doing, so you don't end up installing malware or vulnerable versions.

            Is it imperative in order to have proper security, to use AppVerifier along with it?

            If an app verifies with AppVerifier, you put the trust in AppVerifier instead of yourself or F-Droid. So generally, that would be a very good choice over using Obtainium without AppVerifier.

            n2gwtl

            n2gwtl A lot of privacy focused apps have directed us to download from FDroid - Molly, Thunderbird, Proton.It is very difficult to make a right decision from the beginning because of the lack of clarity.

            I agree. This is quite problematic as it gives the user the idea that F-Droid is secure and trustworthy. Especially when you got big apps like those on there. Actually pretty much most of the only decent VPN providers are on there as well. Which as you said is only a problem cause of the lack of clarity and information.

            n2gwtl Moving away from FDroid now feels like the transition from an IPhone to GrapheneOS. Too many apps configured to work with a homelab that now all have to be redone.

            Depends on what apps you use. Most of my apps had backups or were even configured to use data outside of themselves entirely so my transition only really took a few hours at most.

            ParanoidAndroid

            ParanoidAndroid F-Droid's security is a point but when F-Droid builds the app it is more or less guaranteed, that the app was build from the source code. This is not the case when Obtainium is the installation-source because the signature that can be verified has nothing to do with the Code.

            The bigger question here is do you trust them to take care of everything for you or not? If you trust them enough then use them.

            ParanoidAndroid If my assumption is correct I don't get why I should trust many developers when using Obtainium instead of only trusting F-Droid. Isn't the Security compromised with each app that is installed and updated via Obtainium?

            As I said you are still trusting the developers to an extent especially since as mentioned F-Droid's security checks are rather... Bad and ineffective currently.

            In terms of obtainium you are partially correct especially if you do not manually verify them yourself. The concept of the way obtainium is often suggested over F-Droid is that you don't have a extremely insecure source managing all of your apps. Obtainium isn't necessarily insecure or secure in the sources that it connects to (depends on the source of course) but it does have issues that have been discussed which while don't make it a necessarily insecure option they do make it a problematic option as how it handles things in my honest opinion is not a good nor reliable way to obtain apps unless as a last resort which is why I mainly use RSS and just do everything manually including the verification processes.

            There's evidently reasons why GrapheneOS doesn't actually recommend or suggest Obtainium.

            Because just like F-Droid it is problematic except in some different ways. The only problematic thing they really share is that they both break the Android trust model due to them both being able to basically add any third party source they want while technically being a app store.

            Me personally I avoid Obtainium as much as possible except for places where RSS feeds cannot cover. Which so far is only one application so I would say that is going pretty well. And even then I plan to resolve that to where I can get rid of obtainium entirely.

            Point being. I trust myself enough to where I can manage everything myself. Because if a developer all of a sudden turns malicious and ships a malicious update. Or the app is spyware. Well I'm rather confident in my ability to be able to notice and detect that and then when I do it's time to pull the app from my Device and feeds. And for the installation process after being notified of an update I use Vanadium to download it (wouldn't trust any browser with lesser security for such a task) and then do check and verify it if possible and then after installation keep a really close eye for any suspicious activity for the initial week of installation. Of course. I do plan to shift from RSS to Accrescent as it matures but until then...

            But I know everyone is different and you may not be as confident in doing so. Which is perfectly fine and understandable! After all that's a pretty big position to take for most and some people may just simply not be able to do it for one reason or another.

            That's precisely the point I'm trying to make about F-Droid is do you feel like you yourself trust it enough to let it manage your apps despite it's security issues? You can listen to people go back and fourth about pros and cons but not every solution is for everyone. There are legitimate reasons to use F-Droid as are there legitimate reasons to use any app source.

            Think for yourself. Do you trust yourself to manage your apps more or F-Droid? Because that's basically what you have to do with Obtainium or RSS is manage security yourself.
            Come to your own conclusion on what you yourself want to use. What you think is better for you. Cause honestly this Obtainium versus F-Droid stuff is just going to keep going on and on cause both sides have issues. And it's precisely these reasons why I am not giving you a suggestion myself.

            Hope this extra info and explanation helps you make a decision!

              DeletedUser95
              Thank you so much for this! I think it is one of the best and summarized explanation for this discussion, I think it is important to understand why you should trust this or that or why you should not. I think in many discussions this comes too short.

              DeletedUser95 for the installation process after being notified of an update I use Vanadium to download it (wouldn't trust any browser with lesser security for such a task) and then do check and verify it if possible

              Would you please give more detail on how you are doing apk verification after download? I assume you are using Appverifier on the device for as many as possible, correct? Are you also doing a parallel download into a desktop environment and using apksigner in the terminal and then comparing shasums back to Appverifier? Do you have another method on-device? Thanks

              a month later

              Can we get clarity on FDroid? It seems that security is fine if apps host their own repository. App developers build and sign the apps in their own repository and FDroid does it if it is in the main FDroid repo. What can we say about Izzy's security?

              Reference: https://simplex.chat/fdroid/

                n2gwtl The security of F-Droid repos depends on the security of your F-Droid client app. The official F-Droid client apps come from F-Droid, third-party forks of them still contain code from F-Droid due to forking, and other third-party client apps that aren't forks of the official apps still carry the risk of trusting an unknown third-party client app that god-knows-who created.

                n2gwtl The official F-Droid repository and Izzy's repository are highly untrustworthy sources of apps which should be avoided. F-Droid itself and the repository system have poor security. The official F-Droid repository has massive usability and security issues with how they do builds and signing. The issue brought up in this thread is pretty close to irrelevant with very little impact and has little to do with the real, severe problems with them.

                After this thread was posted, I thought back to why I've started to use F-Droid in the first place. F-Droid, and open source software in general, was never meant for security. The only security benefit of open source software per se is that the users are allowed to not depend on the software author's trustworthiness. Note that this is different from not depending on their trustworthiness, it's being allowed to not depend. One of the beneficial goals of F-Droid was also to gather open source apps that may not be entirely freedom-respecting, and either strip them of the freedom-disrespecting parts and/or mark them appropriately. This was supposed to be for the benefit of freedom, not for security. Furthermore, the idea that F-Droid should responsibly build and distribute the apps they offer, including enabling reproducible builds, is not supposed to be a security benefit of F-Droid, it's a basic responsibility that they willingly don't fulfill.

                I like the idea that there's a catalog of freedom and privacy-respecting open source apps and that someone curates based on their quality and security, but while F-Droid does have some high-quality apps, they're neither curated as aforementioned, nor built and distributed responsibly.

                There's also the argument that the fact that F-Droid signs the apps using their own keys adds an additional point of failure — I understand the argument but personally I might not have a problem trusting an additional party, if they were acting responsibly. F-Droid clearly doesn't. And the apps they sign themselves hijack the package name, which prevents the ability to have both the original version and the F-Droid version side-by-side, and prevents easily migrating data to leave the F-Droid versions of apps.

                So can people please stop saying that they want F-Droid for better security?

                  @Artr Your assumptions are completely wrong and there's no need to post assumptions here in the first place. If it takes them half a year to notice WireGuard including a self-update system against their policies, what makes you think they're even looking at the release notes let alone at the actual code? It's simply not what they do. They are not actually reviewing the code in the way you think but rather are doing things based on half-baked scanning and user reports.

                  F-Droid is a highly untrustworthy group of people consistently involved in cover ups of vulnerabilities and attacks on security researchers including harassment. We advise against using it for even a single app. Get the apps directly from the developers instead and you're avoiding trusting highly untrustworthy people as a middleman who are consistently doing the opposite of protecting you. They aren't going to protect you from a compromise where hidden malicious code is included in practice unless the people doing it completely lack any attempt at stealth which would include them doing similar scans themselves to make sure it's not going to get flagged.

                    n2gwtl We've been clear the official F-Droid repository is not a trustworthy source of apps and that F-Droid is not a secure or recommended way to obtain apps in general. Apps which are serious about security should provide a better way of obtaining and updating their app such as including a self-update system in the app.

                      GrapheneOS If this was a reply to my post, I withdraw my assumption. It was based on the timing of the first published article and its eventual discussion in Hacker News. After this, F-Droid published the basic version of the client with fewer privileges as a fix to the lower-hanging fruits of the complaints about their security practices. It does not necessarily mean the first article caused the changes. I only (as you corrected) wrongly assumed the chain of events. Despite this, a distribution system that can be compromised easily is not an option.
                      As for the goals, they have nothing to do with the team or the project; the goals, objectively, are deemed necessary, and (unfortunately) there are no alternatives that can deliver those objectives right now. The most unfortunate, however, is that this topic of discussion has been around for over 3 years and is directed at the people rather than solutions.
                      I can see how some of their community members' replies target a person and offend them in their blog posts. I hope the discussion here can be more about how an ideal replacement would operate if it were to stick to the above mentioned goals.
                      A direct APK distribution system is not a replacement.
                      A distribution system which controls developer keys is not a replacement.
                      A distribution system that can selectively update apps and libraries of a particular device without user knowledge is not a replacement.
                      Instead of enumerating the badness of a particular project or the team members, the discussion could be about the goals of an alternative project, which will probably be more helpful in redirecting resources towards better projects.