GrapheneOS 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.
Where and why would they import APKs? Aren't they building everything from source? If they are importing already pre-compiled APKs without verifying them through reproducing the builds, that is a pretty big issue in my threat model, even if there are no certificate pinning bypass.
GrapheneOS 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.
Yeah, that is what I tried to say.
GrapheneOS Why should GrapheneOS users trust people engaging in such underhanded tactics with the critical role of building and signing most of their apps?
Because, unfortunately, there are no alternatives.
missing-root do you agree that the "xz" situation can always happen if you blindly trust app devs without reproducible builds enforced and checked for each update?
Yes, and that is not even what I worry about the most.
App developers seldom has the expertise and capabilities to build their apps in secure environments, they just build them on their regular computer. Most of them probably just store the signing key there too, not protecting it using dedicated hardware at all. Who knows how many more than the app developers can modify or sign the releases. Individual app developers may also easily comply to sign malicious builds if persuaded to do so by an authority. I think it is fair to say it is mostly only developers of privacy apps, and cryptocurrency apps, that gets it right, and even then they have been hit by supply chain attacks repeatedly, while traditional Linux repositories have been able to withstand that better, even if only because of being somewhat slower moving. The xz backdoor failed, because they targeted those slow moving Linux distributions, but many have lost all their cryptocurrencies because of the wallet app they were using upgraded to a malicious dependency, without the developer knowing the dependency was compromised, and it was all deployed to end-users within days.
The ones who maintain an app repository is expected to be able to build apps in a secure environment, to maintain signing keys using dedicated hardware in a secure way, and to be able to act on reports of backdoors and security vulnerabilities even when the app developer isn't.
The whole situation here is because F-Droid isn't trusted to carry that role. But there literally are no other app repository that even attempts to do it. So there are no alternatives.
missing-root Having a security model like Accrescent, where app devs do whatever they want and the chain of trust uncontrolled starts on their desk, is problematic.
Yes, I have zero trust in Accrescent. They take the pre-compiled APKs from the developers, do not perform any verification like reproducible builds or anything, and have despite their very small number of apps already accepted one with a bundled affiliate link with a tracker, and seem to not care about that. (Organic Maps, by the way, F-Droid removes that tracker.)
xuid0 The solution as others keep mentioning seems simple. Don't use F-Droid or any client for it.
Unfortunately, there are no options for me.
xuid0 Use Obtainium
That would go from having minimal peer review to having no peer review at all. Absolutely not a suitable choice in my threat model. I need that peer review, my security very much relies on that.
xuid0 Google Play store app
They outright permit and promote apps with very privacy invasive and freedom restricting technologies. They very evidently do not care about privacy at all, so how could I trust any app installed from there. At best, it could be like using Obtainium.
xuid0 Eventually the F-Droid way of life will end (we can only hope).
Unless we have an alternative by then, it would probably be the point at which I have to stop using phones for security and privacy sensitive things.