Certificate issue about nostros

[KoalaSat]

Hi @IzzySoft I created this pre-release which I believe now has the right certificate, is there a way to validate it or should I just release it?

https://github.com/KoalaSat/nostros/releases/tag/v0.3.3.3-beta

[KoalaSat]

Thanks a lot! Perms updated here with description. Looking forward to the "blob-free release" then 😉

I'm creating the commit now 👍 I checked again VT and now it seems to be just 1 warning, I'll check it anyways

[IzzySoft]

There're quite often 1 or 2 engines reporting "something" lately it seems. Usually it's minor engines. And I wish there would be a link to information of what they think they found… But yeah, can't hurt looking, thanks for the efforts!

[IzzySoft]

@KoalaSat any chance you'll address this? Next round in about a week will remove the apps where there was no response.

[KoalaSat]

@IzzySoft sorry for the late reply,do you know if this is something that suddenly happened? or was it always like that?

[IzzySoft]

@KoalaSat It probably was that way for quite a while now. I've introduced certificate pinning about a year ago – so around the time Nostros was added to my repo. Which means it was always the same key/certificate since then, as if there was a certificate change that would have popped up earlier. This is what the signing details look like:

package: name='com.nostros' versionCode='78003' versionName='v0.3.3.2-beta' platformBuildVersionName='13' platformBuildVersionCode='33' compileSdkVersion='33' compileSdkVersionCodename='13'
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: CN=Android Debug, OU=Android, O=Unknown, L=Unknown, ST=Unknown, C=US
Signer #1 certificate SHA-256 digest: fac61745dc0903786fb9ede62a962b399f7348f0bb6f899b8332667591033b9c
Signer #1 certificate SHA-1 digest: 5e8f16062ea3cd2c4a0d547876baa6f38cabf625
Signer #1 certificate MD5 digest: 20f46148b72d8e5e5ca23d37a4f41490
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: 06104aa0b28fac286bae06b08313ac69c37c35a6462853db32d2ec5fa7b1ed0e
Signer #1 public key SHA-1 digest: 88325602a013a12d5ac13516c609aa57ce9e2234
Signer #1 public key MD5 digest: 49921988ad9941656cd9b95203196f17

The DN marks it as debug certificate (that's what debug certificates use).

[IzzySoft]

LGTM:

package: name='com.nostros' versionCode='79003' versionName='v0.3.3.3-beta' platformBuildVersionName='13' platformBuildVersionCode='33' compileSdkVersion='33' compileSdkVersionCodename='13'
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: O=Nostros, CN=Nostros
Signer #1 certificate SHA-256 digest: 949348dc252058d67fae27d7d31f1f21a23d846906d25c8b4c16e51d691e15d7
Signer #1 certificate SHA-1 digest: ae347cad3b893168f3e3766aa7b7ea91ce1f52ed
Signer #1 certificate MD5 digest: ce08fa796b38623a83d07bab2bad0b45
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: abb09b8aa163fbb3a1c2e6a591bc06e227535a1357676322d8e73076660440b5
Signer #1 public key SHA-1 digest: 0aea03c87eeccb61eb34dc6ae34c444f4f28489e
Signer #1 public key MD5 digest: 08279d6e3531abf95e54e762099662a6

Thanks, good to go I'd say! I'll then put a release note here in the local fastlane on my repo that folks need to uninstall and reinstall to switch to the new line. I've already added the new certificate to the AllowedAPKSigningKeys for Nostros, so the update won't be rejected when it comes in. Will leave the old one up for a week or two before removing it, giving people time to check and switch.

That fine with you? Then I'd say make it a release and let me know, so I toggle my updater and put everything in place here.

[KoalaSat]

Sounds good @IzzySoft thanks for the support!!

[IzzySoft]

OK, done then. Scanner reports on update:

! repo/com.nostros_79003.apk declares sensitive permission(s):
  android.permission.READ_EXTERNAL_STORAGE
! repo/com.nostros_79003.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Can you please clarify what the read/write storage is needed for, so I can add the permission to the "allow list"? As for DEPENDENCY_INFO_BLOCK, that can easily be avoided:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        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.

Oh, and something-something at VT complained, just to let you know. Two minor engines, most likely false positives.

[KoalaSat]

OK, done then. Scanner reports on update:

! repo/com.nostros_79003.apk declares sensitive permission(s):
  android.permission.READ_EXTERNAL_STORAGE
! repo/com.nostros_79003.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Can you please clarify what the read/write storage is needed for, so I can add the permission to the "allow list"? As for DEPENDENCY_INFO_BLOCK, that can easily be avoided:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        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.

Oh, and something-something at VT complained, just to let you know. Two minor engines, most likely false positives.

Nostros not only downloads the notes in memory but also to an internal DB. There is a feature where the user can export in a JSON file all his historic. I have also a plan to implement an import action.

I'll check DEPENDENCY_INFO_BLOCK, thanks for the hints!

That thing on VT was weird I'll also investigate just in case 👍

[IzzySoft]

Thanks a lot! Perms updated here with description. Looking forward to the "blob-free release" then 😉