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.
Conversation
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.
1
5
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
F-droid does sometimes have a feel of a graveyard of unmaintained apps, so a core system of monitored apps which are seamlessly updated would be awesome for user experience. Also, thanks for introducing me to Mollyim! First I have heard of it.
1
3
It's made by someone in the GrapheneOS community so for the most part it's known about by people using the GrapheneOS channels on Matrix / IRC.
We have arrow goals for our app install / update system: GrapheneOS only, minimal UI, highly secure and robust, option of automatic updates while making sure to avoid disrupting the user by restarting the app they're using (unless they just switched to it while updating), etc.
1
5
Delta updates, small set of packaged apps that's possible for us to maintain very well including jumping off points to other app ecosystems (like F-Droid) and so on. That's the way we approach these things in general. Realistic, incremental approach headed towards bigger things.
1
5
Show replies