And if you're going to add signatures please don't make them MD5/SHA1. I don't understand why so many sites still offer those. Is it some default feature of some software stack where developers just "check" a button for signatures and it only supports MD5/SHA1? Otherwise I can't explain it.
In Windows world, you basically have to use SHA1 digests for digital signatures (though you use SHA2 certs to do the signing) as Windows XP doesn't support SHA2 at all, Windows Vista SP1 or SP2 prior to a patch a view years ago won't run the EXE or show an error due to a buffer overrun, and Windows Vista's Internet Explorer full patched will show the download as "reported unsafe" due to an unfixed bug in IE.
I was giving an example of a context when using something stronger than SHA1 doesn't work even though it is supported. To show that there are sometimes reasons other than laziness and on the off chance that there may be something similar with specific versions of Android or possibly some software that deals with APKs.
I recommend RSA (GnuPG) or Ed25519 signatures with two key pairs: A weekly/monthly signing key pair, and a long-term one that is only used to validate the short-term public key.
Verifying signing keys is one thing, but even better, f-droid.org can verify that the APK builds 100% from source, and that the APK f-droid.org builds matches the developer's official released APK:
https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...
What would the OS check the signature against, though? The certs that come with the OS are for validating sites, not apps, so passing a check wouldn't tell you much. It seems that Android would have to add a whole new cert store (and mechanism for adding certs), not just a couple of lines.
That's not true at all. CA and leaf Certs have extensions and policies and can be used for any particular purposes. All the cert verification has to do is check for the code signing extension / policy.
You can use self-signed certificate to sign APKs. Once you publish the signed package, you have to use this same certificate for the package forever.
When updating, the system checks, whether the newer APK is signed by the same certificate and refuses update, if the certificate differs.
It simply does not matter, whether your cert is vetted by CA or not. So using PKI would not make sense there.
The rationale was not forcing the developers to purchase signing certificates in order to publish for the platform. It does not make difference anyway.
The rationale was that Google doesn't want a secure code signing mode as it would undermine their thesis that turning off the Google Play store is insecure.
At least even MacOS has a App Store + Identified Developers. Though of course, iOS doesn't have that..
> it would undermine their thesis that turning off the Google Play store is insecure.
I don't quite understand. How do you turn off the Play store?
It is necessary to make a distinction between what you want to believe and the reality. The reality is, that requiring validated keys would put the keys to the "official Android" kingdom into CA's hands. In addition, because Android is an open-source project, any alternative distribution would disable that. It would cause real fragmentation of the platform, where apps would run on one distribution and not on another, the difference would be only the signature. Google (correctly) decided, that they do not have to fight this fight.
A side note: getting CA verified can be problem in some parts of the world. What if you are Chinese? Crimean? You can still use Android as it is; you can't use any platform, that requires to be "Identified" by CA.
It is worth keeping in mind that the download stats which determine popularity [0, 1] should consumed with care. They represent HTTP requests which hit the server to download a particular apk file. Thus, things such as web crawlers can trigger downloads, which result in incrementing the download count.
Having said this, they definitely seem to be useful as a general rule of thumb about how apps are more popular, _relative to other apps_.
1. HTTPS, especially for APK downloads
2. Information about the APKs: built/signed by whom