The only reason this didn't turn into a disaster was pure luck.
Is it? Or is it a case of "It rather involved being on the other side of this airtight hatchway"[1]? The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
If you try to update the app. Anyone installing the app from scratch will still be vulnerable. Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". Izzy wrote a blog post about it a while ago.[0]
> and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password)
IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically.
[0]: https://f-droid.org/2023/09/03/reproducible-builds-signing-k...
1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver?
2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly.
>IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically.
Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant.
As far as I understand (I'm not an expert on F-Droid), this validation happens on the server side. The (repo) server verifies that the signature matches that of the first version it saw, the phone (when installing the APK) verifies that the signature matches that of the first version it saw.
Android keeps the fdroidserver honest for upgrades, fdroidserver provides an additional bootstrap point for Android's trust.
> 2. Even if this actually affected the f-droid app, what you described seems like a very modest increase in security. The attack this prevents (ie. a compromised server serving a backdoored apk with a different signature) would also raise all kinds of alarms from people who already have the app installed, so practically such an attack would be discovered relatively quickly.
Sure, it's the difference between "automated tooling sees the problem immediately and addresses it proactively" vs "hopefully someone will ring the alarm bell eventually".
> Doesn't f-droid perform the build themselves and sign the apk using their own keys? They might be pulling from the upstream repo, but that's in source form, and before apks are signed, so it's irrelevant.
According to the linked blog post, not anymore. Apparently, these days they serve the author's original APK, but after verifying that they can rebuild it (modulo the signature itself).