IzzySoft
commented
12 months ago PS: Also APK size has more than doubled, meaning I can no longer keep 3 versions in my repo.
Closed IzzySoft closed 11 months ago
IzzySoft
commented
12 months ago PS: Also APK size has more than doubled, meaning I can no longer keep 3 versions in my repo.
tretdm
commented
12 months ago 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.
tretdm
commented
12 months ago For the latter, I now corrected app/build.gradle (commit 07e27b7), maybe try it with a debug keystore.
IzzySoft
commented
11 months ago 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!
tretdm
commented
11 months ago 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.
tretdm
commented
11 months ago Fortunately, everything worked out.
IzzySoft
commented
11 months ago 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 :see_no_evil: 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 https://github.com/openvk/mobile-android-legacy/issues/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!
tretdm
commented
11 months ago 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.
IzzySoft
commented
11 months ago Strange. The diff suggests otherwise. But :man_shrugging: Solved, luckily :smiley:
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" :wink:
tretdm
commented
11 months ago 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!
IzzySoft
commented
11 months ago 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.
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:
Build 174 (stable) (the previous stable build) used this:
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!