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...
But yeah other repos don't :(
Will it if it's a non Google distro of Android?
The use of AllowedAPKSigningKeys afaik is to compare that key with the key used for signing the dev build. If its not the same, the dev build is rejected.
From what I've understood from this POC, its possible to bypass this signature check. The only exploit I can think of with this bypass is that someone who gets access to the developer's release channel can host their own signed apk, which will either get rejected by Android in case of update (signature mismatch) or gets installed in case of first install. But in either case, its still the same reproducible build, only the signature is different.
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. User downloads an app from F-Droid that supports reproducible builds.
2. The developer's account is compromised and submits an app with a different-than-expected signing key.
3. A new user installs the app (existing users aren't affected due to Android's enforcement of using the same signing key for updates).
4. This user is (external to the app) contacted by the attacker and directed to install an update to the app from them. The update contains malicious code.
F-Droid's response is concerning but this attack scenario seems pretty unlikely to work in practice.
That still enables a supply chain attack, which should not be dismissed - virtually all modern targeted attacks involve some complex chain of exploits; a sufficiently motivated attacker will use this.
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.
>But in either case, its still the same reproducible build, only the signature is different.
That means the attacker still has to compromise the source repo. If they don't and try to upload a backdoored apk, that would cause a mismatch with the reproducible build and be rejected. If you can compromise the source repo, you're already screwed regardless. Apk signature checks can't protect you against that.
Which post are you talking about? >>42592150 was made by FuturisticGoo, not me.
Also, the wording on f-droid suggests the version that f-droid hosts is built by them, rather than a version that's uploaded by the dev. If you go on any app and check the download section, it says
> It is built by F-Droid and guaranteed to correspond to this source tarball.
It also allows the user to place a little less trust on F-Droid because the developer, as well as F-Droid, must confirm any release before it can be distributed. (Now that I think of it, that probably creates an issue where if malware somehow slips in, F-Droid has no power to remove it via an automatic update. Perhaps they should have a malware response or notification system?)
More: https://f-droid.org/2023/09/03/reproducible-builds-signing-k...
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).
But obviously only for newly submitted apps that can be built reproducibly. Old apps, or even new apps that fail to build reproducibly, continue to be built to the old model with an F-Droid-provided signing key.
(Even if an older app can actually be built reproducibly these days, it'll still be stuck on having to continue using the F-Droid signing key – key rotation is only supported from Android 9 onwards, and for some reason Google only recommends its actual usage on Android 11 and newer, and then you still need to manage the transition period somehow where app updates need to be dual signed, and once you stop that dual-signing, everybody updating from an old signature needs to install one of those dual-signed versions first before being able to install a version only signed with the new key.)