Wrong signing key?
IzzySoft opened this issue · 12 comments
It seems the APK files attached to 1.1, build 212 are signed with the wrong key, thus making updates impossible. This is from the release APK:
Signer #1 certificate DN: CN=Dmitry Tretyakov, OU=OpenVK Legacy Team, O=OpenVK, C=SU
Signer #1 certificate SHA-256 digest: f2c0f9fd836df7d447b1f45106bcb3e48f6effd28639fd7afbf329451bae1710
Signer #1 certificate SHA-1 digest: 829c4d01cb2c78ef19b02b754017466312d6c947
Signer #1 certificate MD5 digest: 8bb15ac8ae338019fc858b340b08444d
Signer #1 key algorithm: RSA
Build 174 (stable) (the previous stable build) used this:
Signer #1 certificate DN: CN=Dmitry Tretyakov, OU=OpenVK Legacy Development Team, O=OpenVK, L=-, ST=-, C=7
Signer #1 certificate SHA-256 digest: 147432adb528da6c6d6fc4a2ba3d0a0f439ad77b540e91afa15fe97e564de08b
Signer #1 certificate SHA-1 digest: 1de154694b988d0a7e74392c5a1a3da3ba2ad65b
Signer #1 certificate MD5 digest: c5338e60e3edaa14ce9b8935fe29d8d7
Signer #1 key algorithm: RSA
Release notes on the latest stable release give no clue. Skimming the notes on the pre-releases in between, it seems the certificate/signing-key was changed with 1.1 build 177 (alpha) ("Due to the fact that the test signatures do not match, a direct update is not possible.") Was the original key lost? What happened to cause a switch? Could you provide an APK of the latest stable release to confirm a proper transition (you being in control of that key would eliminate the doubt of a possible "imposter" or "hostile take-over")? Thanks in advance!
PS: Also APK size has more than doubled, meaning I can no longer keep 3 versions in my repo.
No, I signed release APK (app-release.apk) with new created keystore (it is for production, not for debug). It used to be the other way around, and it’s unreasonable, so I decided to re-sign APKs.
I can either provide the store with passwords from app-release.apk, or advise you to sign with either F-Droid keys or debug-ver keys, signed in app-debug.apk.
For the latter, I now corrected app/build.gradle (commit 07e27b7), maybe try it with a debug keystore.
It's not about the listing at F-Droid.org, but the listing in my repo (which was requested explicitly despite of the already existing listing at F-Droid.org. F-Droid builds from source, my updater just takes the APK provided by you.
Could you, for a one-time verification, provide a build matching the APK at build 212 which is signed by the "old key"? That would allow me switching to the "new key" in my repo then. Thanks in advance!
Okay, so I found keystore from 1.0.174: https://github.com/openvk/mobile-android-legacy/blob/9c7c1c62b7af9967ecc8fb6a36b99faf583da450/app/OpenVK%20KeyStore.jks
I will be build APK completely with this key tomorrow, unless of course it causes another problem with power supply, I don’t have a laptop.
Fortunately, everything worked out.
Thanks! Unfortunately, comparison failed. Are you sure both APKs have been built from the same commit?
--- /dev/fd/63 2023-11-20 02:25:38.362029830 +0100
+++ /dev/fd/62 2023-11-20 02:25:38.362029830 +0100
@@ -1,13 +1,13 @@
AndroidManifest.xml
- 32-bit CRC value (hex): aac88825
+ 32-bit CRC value (hex): be579dc9
META-INF/CERT.RSA
- 32-bit CRC value (hex): 3b43645a
+ 32-bit CRC value (hex): 0d7a0d57
META-INF/CERT.SF
- 32-bit CRC value (hex): 68b2c0ea
+ 32-bit CRC value (hex): f5fb2367
META-INF/MANIFEST.MF
- 32-bit CRC value (hex): 82edc9bb
+ 32-bit CRC value (hex): e09bd806
classes.dex
- 32-bit CRC value (hex): 90f2e175
+ 32-bit CRC value (hex): a0a8a99b
okhttp3/internal/publicsuffix/publicsuffixes.gz
32-bit CRC value (hex): 5fccc77e
res/anim/abc_fade_in.xmlAccording to that, there are differences in AndroidManifest.xml (a direct compare of the two decompiled ones funnily did not show any differences – but the binary ones differ in size by 4 bytes); the certs (which we can ignore here as that is expected due to the certificate change), and the classes.dex (again 4 bytes size difference). Ah, there it is: AboutActivity shows two changed values. const-string v17, "1.1.212-f" probably means you've given the F-Droid build a different versionName – and const-string v17, "faabfb2" (fdroid) versus const-string v17, "b32fe6a" (release) could indicate a different commit being used. Yupp, I find matching commits for both – so there's the culprit.
For a successful confirmation we need APKs built from the very same commit, unaltered code, just signed by the respective keys.
But hey, we're not setting up reproducible builds here 🙈 You've just proven you could produce an APK from the latest commit, signed by the original key – for my repo, that's all we need. So thanks a lot for your efforts: I've just re-enabled updates for your app, and placed the 212 APK (which I had here already for the comparison) into the repo. Will remove the old key hash from AllowedSigningKeys once 174 was "aged out". There was no 212.txt with your Fastlane changelogs, so I took the freedom to create one:
signing key changed, so you will have to uninstall and reinstall the app. For details, please see #152
To make those already having your app installed aware of what they have to do now.
TL;DR: Thanks, all done! Wish you undisrupted power – and peace in freedom!
Thanks! Unfortunately, comparison failed. Are you sure both APKs have been built from the same commit?
Actually yes, since only the build.gradle and mobile-android-legacy.iml files were affected, but the keystore from 1.0.174 was returned back.
Strange. The diff suggests otherwise. But 🤷♂️ Solved, luckily 😃
Btw: I don't know if it's a good idea to have the keystore checked in. I hope at least your passphrases are in a "different place" 😉
I hope at least your passphrases are in a "different place" 😉
Yep, the key in app-release.apk will be controlled by me, with the exception of the other two (app-fdroid.apk and app-debug.apk).
You're welcome!
My updater will ignore the debug one as long there's any other APK available. And the -fdroid one was just needed for a one-time verification (so no need to have that with future releases). Which means we're fine now. You'll just provide the release and debug one with future releases, right? Otherwise I'd need to tell my updater explicitly which APKs to pick.