Certificate issue about koduko HOT 6 OPEN

@Mazahir26 Any chance? Or did you abandon development of this app?

from koduko.

Hey! Sorry for the late reply. I would like to use a proper release key, But I don't know how to do that. Any help would be awesome or give me some time to figure it out.

Thank you so much for reaching out!!

from koduko.

I'm not an Android developer, so I can just point you to the proper documentation giving some "basic hints". I'd recommend using apksigner for signing. Unfortunately, its documentation does not include generating your keys first, so we need another one. Let me check the search engine again… Ah. There's the official documentation for KeyStore – however, it's rather more focused on technical details. Easier and straight-forward instructions can be found in this StackOverflow answer, which suggests running

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

You will then be prompted for some details like your name, organization, location etc. While you can skip some, I recommend to at least fill some of them to make clear it is your key. E.g. you don't need to give your "real name", but should maybe at least put your nick ("Mazahir26") instead; you can entirely skip the "organizational unit" and even the "organization", but it might be helpful to at least place the country. All that is of course up to you.

Done that, you can verify results using

keytool -list -v -keystore my-release-key.keystore -alias alias_name -storepass mypassword -keypass mypassword

(if you don't want to specify the passwords as options here just skip those parameters, and you should be prompted for them).

As that post is from 2013, algorithm and keysize used should be checked again if they are still meeting today's requirements (the validity of 10000 just sets the expiration date to 10,000 days (approx. 27 years) into the future, which should be perfectly fine. And as even recent articles use RSA with 2048, that should be OK too – if you want to increase security, you could use keysize 4096 instead.

Note that I do not recommend using Android Studio for this (and especially not for signing) as that has some implications FOSS-wise – e.g. signing injects some binary stuff which is proprietary (and encrypted at that, so it's hard to impossible to verify).

Oh, now that I wrote up all that I find an easy how-to at StackOverflow with step-by-step instructions 🙈 I'll leave the above in nevertheless as it might be helpful, too.

from koduko.

Hey! I have updated my releases with properly signed keys, Can you verify the same?

Thank you.

from koduko.

Thanks! The certificate looks good now. But two findings still. First, it seems you didn't use any of the approaches above but took Android Studio for signing?

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

That is an opaque block Studio injects by default. It's encrypted with a public key belonging to Google, so only Google can tell what's really inside. If you really want to use Studio for signing, maybe you can add this snippet to your buld.gradle?

android {
    dependenciesInfo {
        includeInApk = false
    }
}

Next I see you updated your versioning:

package: name='com.example.koduko' versionCode='2001' versionName='1.0.2'

This is the arm64-v8a APK taken from release v0.1.2. So your tag names do not match; my updater refused to pull anything, as 0.1.2 < 1.0.0. May I recommend to have the tag names follow the versionNames with future releases?

Last thing is versionCode. The 2001 there means it's still versionCode 1, as if it were the very first release, just for the arm64 ABI (Flutter adds a "2000" for that ABI). This being the third release, it would be expected to be "2003" (or a higher last digit). This is easy to fix here, you just need to add the proper versionCode to the version line:

version: 1.0.2+3

Without that, nobody will ever receive any updates, as Android internally uses versionCode to tell versions apart. If the versionCode did not change, it's not considered an update.

I've manually added the latest version now, as this time 2001 > 1 updates should be applied (I've picked the arm64 variant; with it's size down to ~10 MB, there's now be up to 3 versions kept in my repo instead of just a single one before, as the per-app limit of 30 MB allows that now). And I suggest starting applying these updates button-up: fixing versionCode (for the next release) is the easiest one 😉

Thanks a lot!

from koduko.

Yeah I also was running into the issue with the version code. Using Obtainium to keep track of github releases btw.

from koduko.