Comment by _flux
15 days ago
They have a reason mentioned by others, however what was news to me that the Google Android application registration also requires them! https://developer.android.com/developer-verification#registe... says
Register your apps: You'll need to prove you own your apps by providing your app package name and app signing keys.
Couldn't this also be verified with a challenge-response signing, using the key? Why should Google have the ability to sign apps of the developer, instead of it being an end-to-end deal? Perhaps they need to have the ability to slip in some additional code if the government so wishes?
Or perhaps there is actually a legit reason for Google to have those keys or I have a misunderstanding of the requirement?
Maybe F-Droid could relax that requirement if it were feasible to do reproducible builds. Then the developer could just deliver the package to F-Droid, F-Droid would check that it matches what they have, and then publish it. But that's probably not going to happen. Alternatively some deeper proof-based certificate could be devised, but that's even less likely to happpen..
To be clear it sounds like the upcoming "Android Developer Console" (distributing APK outside Play Store) https://developer.android.com/developer-verification/guides/...) does *not* require you to disclose your private key, only prove ownership:
> Select your key: Choose your public SHA-256 fingerprint certificate from a list of eligible keys.
> Complete a cryptographic challenge: You must sign a dummy APK with the corresponding private key and upload it to Android Developer Console. This formally verifies your ownership of the key used to sign your existing Android app.
Play Store on the other hand does require you to share keys, so they can optimize your APK for each device. And maybe inject some state malware if you want to be snarky.
They already have required it since 2021.
https://support.google.com/googleplay/android-developer/answ...
The main benefits is that Google is able to optimize downloads for individual devices. It also makes the situation where the developer loses a private key and then they can no longer push anymore updates to their app no longer possible. I'm not a fan of this approach of essentially allowing Google free reign to use your key for deploying jpdates.
> The main benefits is that Google is able to optimize downloads for individual devices.
I don't think Google does the more invasive bit of stripping out non-applicable code protected by API level checks (Build.VERSION.SDK_INT), and otherwise, the simple splitting up of native libraries by ABI, graphics resources by display density and string resources by language (plus any additionally defined code modules for on-demand download of optional features) could have been done wholly locally, too, including signing.