Signing key changed?
IzzySoft opened this issue · comments
Until before the latest release, APKs were signed using a key with the hash of 26926063ecd5ae5d4cc9c56f220dd48f942a4712cc86a25f06be4cef8c8a4a3f. Today's release suddenly uses one with the hash a2fa8444bc3a0b5c08b9aa48cc5a284f147da6e2bd654aac73b1464031c19b6f, and thus was rejected by the updater in my F-Droid repo – as it will be rejected by the Android devices already having your app installed.
Could you please tell what happened? Thanks in advance!
Hi,
I switched over to using a new computer and I just realized my signing certificates were probably not transferred over since I normally would build the android files under Linux. I can transfer over the certificates in the next day or two though?
Sure, you can then simply replace the current APK with the newly signed one, so not only would then updates be possible again on-device – but my repo updater would accept them, too. Just let me know please once you've replaced so I can make sure the "old one" isn't blocking things.
Thanks a lot! 😍
PS: Should you one day really need to change the signing key, consider also changing the applicationId at the same time. The com.example. prefix is not meant "for production" 😉 No issue with my repo, but e.g. PlayStore would not accept it.
@Kara-Zor-El friendly reminder that the 2 days have passed twice 😉 Any update/ETA?
Hi, apologies, my old laptop wouldn’t even connect to the internet or launch a DE correctly so got it working last night but was too tired to transfer over the keys. Will do so today
Thanks for the heads-up – and no pressure! I just wanted to make sure it isn't forgotten. Glad to heat you got it working finally – best luck for retrieval of all relevant data! 🤞
Hey,
Sorry for the lack of updates on this. I realized that the key I was using to sign the previous one was a debug key and not meant to be used in properly published apps. I have fixed this and now use a release signing certificate that I have generated. I am unsure of how those hashes were originally obtained but the next releases key hash is the one you should use. Does that make sense?
Yes, that does make sense. Please let me know when that APK is there, I have to manually add it then while adjusting the hash (which was obtained with apksigner at the time the first APK was fetched and added to my repo).
If you could attach an APK signed with the original debug key as well (for confirmation, name it e.g. app-debug.apk) that would be good; I'd then let you know when I had checked that so you could remove it again if you wish – or let it stay so other people could confirm that for themselves if needed.
As far as I can tell, only the latest release (v1.2.0) was signed with a debug key:
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: a2fa8444bc3a0b5c08b9aa48cc5a284f147da6e2bd654aac73b1464031c19b6f
All previous releases (that I checked) are signed with the same key that the version in Izzy's repo uses:
Signer #1 certificate DN: CN=Kara Wilson, OU=Unknown, O=FA, L=Toronto, ST=Ontario, C=CA
Signer #1 certificate SHA-256 digest: 26926063ecd5ae5d4cc9c56f220dd48f942a4712cc86a25f06be4cef8c8a4a3f
(this matches the keys Izzy reported above of course)
@Kara-Zor-El do I understand correctly that you lost that release key and had to generate a new one? Because being able to switch back to using the original key would be ideal of course and not require any changes for Izzy or anyone that has an older version installed.
being able to switch back to using the original key would be ideal of course
Not only as it proves nobody "hacked in to your repo" – but also as existing installations could be updated seamlessly 😉
Hi, @obfusk,
I am very confused as to the signing certificate not being the debug one on as if you look at commit a66b779, you can see that prior to this, I didn't use a signing key other than the debug key before this current release.
I still have access to the older machine which should have the key on it. That machine was a GF75 Thin 9SC from MSI running Arch Linux (and for the iOS side, using a hackentosh on the same device). This machine is a M2 Mac Pro. It is possibly that different release platforms or architectures of Flutter use different signing keys possibly. I want to prove that my repo isn't "hacked" like @IzzySoft pointed out. I understand the issue with existing installations being updated senselessly but I have finally gotten a non debug key to work on signing release builds to the best of my knowledge.
This being said, I don't want to necessarily provide duplicates of every build in the same release as I worry that may confuse others. Would perhaps a link to google drive containing signed versions of the normal ones I release be sufficient. Or I could maybe set up one as a pre-release build but just say it has the old signature. You can also contact all the contactable way I have in my repo (I did change the discord from kmp3e#9430 to kmp3e as discord recently updated it to remove the hastags in usernames) and I will validate that it is still me running this repo.
I do want to maintain a seamless translation but I needed to change the signing configs and application ID so that I can begin the process to start properly getting it published on f-droid, the Google Play Store and idk if I will but the Galaxy Store maybe?
If there is anything else I can do, please feel free to reach out.
Kara. :)
I didn't use a signing key other than the debug key before this current release.
Weird. I can indeed see the release build config was using the debug signing config. And yet your previous releases were clearly signed using a non-debug key with your name.
I know that Android Studio's "Build -> Generate Signed APK" will sign releases even if no signing config is configured in build.gradle, but that seems like a different issue. I don't know how flutter handles signing.
I assume you did not replace the debug key stored in ~/.android/debug.keystore on your old machine with the one used to sign those releases? That would at least explain it.
(You can check with keytool -keystore ~/.android/debug.keystore -list -v, the password should be android and the key alias androiddebugkey.)
Of course if you change the application ID, users will need to reinstall anyway, so a different key is less of an issue. It's essentially a different app, also for Izzy's repo.
As for proving you're in control of the old signing key -- assuming you find that -- you could e.g. simply sign an APK of the latest version with that key and upload it to this issue only (and keep using the new key for new releases).
I know that Android Studio's "Build -> Generate Signed APK" will sign releases even if no signing config is configured in build.gradle, but that seems like a different issue. I don't know how flutter handles signing.
I don't use Android Studio at all for building.
I assume you did not replace the debug key stored in ~/.android/debug.keystore on your old machine with the one used to sign those releases? That would at least explain it.
I don't think it would. since the debug builds are still signed with the debug key
Of course if you change the application ID, users will need to reinstall anyway, so a different key is less of an issue. It's essentially a different app, also for Izzy's repo.
Yeah, I have setup a migration piece of code that should transfer stuff over but I have 0 clue if it will work on physical devices as I don't have any physical android devices and with recent expenses can't afford to get even a cheap one to test on.
As for proving you're in control of the old signing key -- assuming you find that -- you could e.g. simply sign an APK of the latest version with that key and upload it to this issue only (and keep using the new key for new releases).
See that would work in theory but the only issue is that you cant attach files to issues unless its a image or video
See that would work in theory but the only issue is that you cant attach files to issues unless its a image or video
You can rename the APK to .zip :)
I don't think it would. since the debug builds are still signed with the debug key
Right. So weird. Would be nice if you could find the keystore it was using. And maybe whatever flutter config pointed to that.
I don't have any physical android devices and with recent expenses can't afford to get even a cheap one to test on.
If you submit your app for inclusion in F-Droid one of our reviewers might be able and willing to test that too.
Alright, awesome
You can rename the APK to
.zip:)
it only allows images and videos. .zip isn't one of the 2 options. I can upload it to a file sharing platform and share it here if that'd work
I can upload a .zip to this comment without issues: test.zip
Oh, my bad. Will send a apk here soon
Hi,
@obfusk unfortunately i can only send files as large as 25MB here but here you go @IzzySoft, a version of 1.20.0 compiled on my old computer that I believe should have been signed correctly. to the best of my knowledge, it is.
If your wondering why the naming is different, I end up renaming each manually before a release (I should probably write a script to do that for me, lol)
https://drive.google.com/file/d/15HRldPaENxuxOvPRMHcl8hr7JfsHGMYx/view?usp=sharing
Hopefully this proves that it is still me :)
Best, Kara
Oof. I wonder if I can get the file from that server (I never use Google Drive, and tracking prevention might prevent me from getting to it). Looks like not: All I get after waiting 2 minutes (while the status bar flashes with hundreds of server connects throughout the entire Google world it seems) is "The page isn’t redirecting properly". OK, retrying a couple of times seems to do the trick. Download will take a while at 250kB/s (via Tor)…
Done. Confirmed: this one is signed by the same key that was used before. So how do we proceed now? The latest release was signed by a debug key, I won't switch to that. As the original key has been recovered: maybe you continue using that one then?
Version code is 19 instead of 20, but the version name matches :)
package=com.example.jellybook versionCode=19 versionName=1.2.0
Izzy's repo has:
package=com.example.jellybook versionCode=2001 versionName=1.1.8
Which would be an issue for updates (but you're changing the singing key and appid anyway).
FYI: the version scheme of 20 (universal), 2020 (arm64), 4020 (x86_64) would not work if you wanted to use split ABI on F-Droid.
But the signature looks good:
Signer #1 certificate DN: CN=Kara Wilson, OU=Unknown, O=FA, L=Toronto, ST=Ontario, C=CA
Signer #1 certificate SHA-256 digest: 26926063ecd5ae5d4cc9c56f220dd48f942a4712cc86a25f06be4cef8c8a4a3f
As the original key has been recovered: maybe you continue using that one then?
@IzzySoft I haven't recovered it. I just built it on the old machine but would rather use the new key. Regardless, we will be starting to use com.KaraWilson.JellyBook so will that cause a issue. I can try to dig into finding the old key after moving but if we are switching apps (since new ApplicationID) in the repo, I'd rather use this key that I know wont do weird stuff and exist in like a quantum superposition or whatever is going on with the previous key on my old laptop
FYI: the version scheme of 20 (universal), 2020 (arm64), 4020 (x86_64) would not work if you wanted to use split ABI on F-Droid.
@obfusk. What? I am genuinely confused as to the version scheme being different. I can investigate that but I have 0 clue why that's happening. I think I would stick to the non-split ABI on F-Droid tho if this is the case because, what? Having different version schemes shouldn't happen as far as I'm aware of
Edit: Apparently this is intended behaviour for some stupid reason (flutter/flutter#39817 (comment)) as such, it might make more sense to ship the app bundle instead?
I can try to dig into finding the old key after moving but if we are switching apps (since new ApplicationID) in the repo
… everyone using the app needs to re-install anyway, right. Fine with me to use a different key then. But:
I'd rather use this key
I have an issue with "this key" as it is a debug key. You should use a release key for signing.
I know wont do weird stuff and exist in like a quantum superposition or whatever is going on with the previous key on my old laptop
Haha, I don't think so. The keystore is a file. And if it works, it is not broken – I guess @obfusk will confirm that with even more confidence than I.
the version scheme of 20 (universal), 2020 (arm64), 4020 (x86_64) would not work if you wanted to use split ABI on F-Droid.
What @obfusk is pointing at is that versioning on F-Droid (and in general – Flutter is IMHO causing some mess here; "some stupid reason" fits that pretty well) should not be using the highest bit for the ABI (1000, 2000, 3000, 4000) to add the real versionCode to, but rather the lowest bit – e.g. versionCode * 10 + ABI, with ABI then being 1,2,3,4. So your versionCode: 20 would result in 200 for the universal APK, 201 for armeabi, 202 for arm64 and so on.
it might make more sense to ship the app bundle instead?
F-Droid has no support for app bundles. At least not now.
@Kara-Zor-El so what are we doing now? For about a month now, my updater daily fetched and abandons that APK. I'm now putting your app on the "slow track", so there won't be daily checks anymore but just monthly ones (they will only serve as reminders to ping you again, as with the current configuration updates are no longer possible). I'm not sure what we agreed upon now, but this is what I hope will be the path to follow:
- you switch to a "proper" packageName, so we get rid of that
com.example.prefix. - you'll then use a release key (either the recovered one or a new one) to sign the APK of the next release
- that done, you'll let me know here so I can check, update my local config to move to the new packageName, and re-enable updates.
Can you please confirm – and name an ETA for when you think to be ready? Thanks in advance!
Hi,
I can release a new build in the next few days so why don't we say 1 week (starting classes tomorrow so really don't know what to expect
Does that work?
Thanks, Kara
Sure! That sounds fine. Please give me a ping then so I check, adjust here, and re-enable updates when all worked out.
@IzzySoft 1.2.1 released
Picked up, replaced the old one – will go live around 6 pm UC then 🥳 Would be nice if you had some screenshots to add. And speaking of adding: be welcome to pick a badge to add to your Readme to link to your app here 😃
And now the standard disclaimer I've adopted over the past few weeks: take good care of yourself – and of your keystore 😜 How to keep your key safe and what measures to take for the event of loss?
Hi, I am gonna close this issue but I will spend some time today adding some screenshots here or perhaps a gif like this here (this is a bit outdated)
https://kmp3e.xyz/images/JellyBook.gif
Thanks! And JPG, PNG are the only supported format. I won't be able to check for the next 3 days, so no hurry 😉
Btw: if you want more control about how your app is presented, consider setting up Fastlane structures here in the repo. Be welcome to use my Fastlane Cheat Sheet for reference 😃
I will take a look at it but i think its safe to close this issue, thank you for your help and collaboration
OK, the original issue is solved, so this should be fine. Just remember to give me a ping when some Fastlane/screenshots are available 😉 Thanks!