What happened to your signing key?

[IzzySoft]

The update triggered our scanner:

! com.criticalay.neer_2.00.00.apk is signed by a certificate that is not allowed: '6248657a9f292d32f4086f3580a6b945c06d0a7a4108d6d37254afe3dc1aea3e'; needs to be quarantined

As you can see by the log message, that update was rejected – as the key doesn't match the one configured for the app. There's no note on the release – so can you please tell why the certificate differs?

[criticalAY]

I lost the signin key, so I had to reset it, on Playstore it is auto updated after my request but other platforms need to be done

[IzzySoft]

I was afraid that might be the case. Then we need to verify again, see How to keep your key safe and what measures to take for the event of loss? – Hm…

• commits not signed
• recorded website (www.criticalay.me) does not resolve (server can't find www.criticalay.me: NXDOMAIN)

Let's hope the other channel is still valid 🤞

[criticalAY]

I will update the readme with latest info, and updated domain is :https://hiashish.com/

[IzzySoft]

Thanks! Received your mail reply as well. Roll-over initiated; website and author name updated as well. As you don't have per-release changelogs, I have created one for this release, so folks are prepared:

!! Signing key has changed, so you need to uninstall any previous version to be able to update and receive future updates !!

While pulling in the new release, our scanner yelled:

! repo/com.criticalay.neer_20000300.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Can you please add some lines to your build.gradle to have that removed with future releases?

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Thanks in advance!

---

One more thing:

your gradle/wrapper/gradle-wrapper.properties lacks the distributionSha256Sum (to secure your builds – at our end, our framework checks that by other means). See e.g. Protecting Project Integrity for the technical background – and for some real-world cases:

• Gradle Wrapper Supply Chain Attack
• Checking for Poisoned Projects

"Our framework": I've tried if we can establish Reproducible Builds – but it failed. One mismatch I was able to counter: Native Library Stripping. Maybe you could disable that?

android {
   packaging {
       jniLibs.keepDebugSymbols.add("**/*.so")
   }
}

To counter this, I had to install the matching NDK (while for building the APK, no NDK would be needed at all). Which seems to reveal that your APK was NOT built with the GitHub Action (GHA) here: it required NDK 27, while the Github runners come with 28.2. Which might also mean the other remaining difference is caused by some specific setup on the machine you build: what are you using? Especially also, which JDK (version and vendor)? We used OpenJDK 17, as your GHA indicated. I would not be surprised hearing you use Jetbrains there. The remaining diff is in classes.dex. As you use obfuscation, I cannot pin it to a given class:

If we can get that fixed, it would be RB. Interested?

[IzzySoft]

As a pointer: we've been seeing similar diffs 2 times now. Both times, it was decided to turn off obfuscation (-dontobfuscate) for R8, to get a clue in which class the culprit lies. We never found out, as after turning off obfuscation, the build was reproducible. Both times. So maybe, just may be, turning off obfuscation for Neer would make it number 3…