zlacker

>>pabs3+(OP)
While none of that applies to F-Droids primary use case (the primary F-Droid repo builds all apps from source itself), it nonetheless looks like they failed to correctly handle the issue.

The only reason this didn't turn into a disaster was pure luck.

>>kuschk+X8
>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...

>>gruez+mb
> 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.

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