Comment by gruez | Hacker News Reader

Comment by gruez | Hacker News Reader

Parent Full thread

>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".

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.

> 1. What you're describing would have to happen on the f-droid app, but the vulnerability seems to be on fdroidserver?

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).

> 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.)

Reply on news.ycombinator.com