Huh thanks for clearing that up, didn't know it worked that way. It seems that F-droid needs some improvement considering how much it is quickly becoming critical FOSS infrastructure.
Conversation
I don't feel like it's on the path to becoming what's needed. For GrapheneOS, we're going to be making our own app install / update system. One of the apps we'll provide in our repo is F-Droid, but we aren't comfortable bundling it with the OS or giving auto-install privileges.
1
11
It has too many issues with usability and maintenance. It has security implications. For example, Android switched to v2 apk signatures in 2016 (Android 7) to address security limitations with the original signing system from the Java world. F-Droid kept using v1 until 2020.
1
12
It could be blamed on lack of resources, but it's their choice to package such a huge number of apps including many that are unmaintained and/or blatantly insecure. Play Store also has minimum API target level for privacy/security reasons, and F-Droid definitely doesn't do that.
1
10
The reason they finally switched to v2+ signatures is that Android starting enforcing it for apps targeting API 30+ as a security improvement. F-Droid had dozens of apps with v1 signatures and API 30+ which all broke for users on Android 11. This impacted GrapheneOS users a lot.
1
9
The apps got detected as invalid after booting up the Android 11 upgrade and forcefully disabled. It's invalid to have an app with v1 signature and API 30+. Unfortunately, the F-Droid developers don't seem to test on modern Android. F-Droid itself has an old target API level.
2
10
F-Droid is focused on older devices and older generation apps for those devices. It's in conflict with privacy and security. We want an extremely minimal alternative to it focused on robustness and security with the option of automatic updates without security / usability issues.
1
1
9
We could then provide users with F-Droid via that system so that they can access a much broader range of apps than what we'll package ourselves. However, that will let us start building a nicer ecosystem via a first party repository and a seamless UX similar to our OS updates.
1
9
Does that mean automatic updates for key apps? Definitely looking forward to that! I'd be very curious to know which/how many apps GrapheneOS would be comfortable pushing in this way, although I suspect it is early in the planning stages.
1
2
Yes, we currently have that via the automatic updates for the OS for the apps included in the OS but we would like to be able to ship updates for Vanadium out-of-band so we don't have to do extra OS releases every 6 weeks (sometimes more often) for the Chromium security updates.
1
5
So, for example, we could package an important app like Element or github.com/mollyim/mollyi. It would have at least one dedicated maintainer making time to fix the issues. First party builds (same local build / signing infrastructure as the OS) and the option of automatic updates.
We wouldn't package many apps. It would only be a few that we consider important. We'd likely package F-Droid and users would be expected to use F-Droid (or Aurora Store, etc.) for everything else. We'd potentially do toolchain hardening, etc. as we do for the OS for those apps.
1
5
We'd also provide delta updates as we do for the OS to minimize bandwidth usage. That's missing from F-Droid. It would be much simpler. The UI wouldn't be fancy at all. Probably just a basic list of app names with descriptions. No need to support legacy permissions, etc.
1
5
Show replies