Question on permissions

[IzzySoft]

Checklist

• I am able to reproduce the bug with the latest version.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.

Affected version

current

Steps to reproduce the bug

Note ahead: your discussions link gives a 404, so I have to pick another issue type here.

My scanner just reported on today's update:

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

Could you please clarify the permissions? Thanks in advance! The DEPENDENCY_INFO_BLOCK is easily healed btw:

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.

Expected behavior

n/a

Actual behavior

n/a

Screenshots/Screen recordings

n/a

Logs

n/a

Affected Android/Custom ROM version

all

Affected device model

all

Additional information

none

[IzzySoft]

PS: What happened to your signing key? This release is signed with a different one than used before, so updates won't be possible. Previous sig:

Signer #1 certificate DN: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Signer #1 certificate SHA-256 digest: 45dd2d0bcc95e8e99a11fe0c8ff0d57899da4712112b83714a29e8b1bfe7c3dc
Signer #1 certificate SHA-1 digest: bdc360be6111c4edee729063565751a66b545542
Signer #1 certificate MD5 digest: 47fffb6367fc9ba91116f2b76fa6931e
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

current sig:

Signer #1 certificate DN: CN=Harley Jones, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=GB
Signer #1 certificate SHA-256 digest: 604a076cc65565bf7a6cc3df151b660963845b69685b3d8487c116dcf4ae60e0
Signer #1 certificate SHA-1 digest: 6a31f0ceaf1e83efda667c593cb03b435c4964d4
Signer #1 certificate MD5 digest: 2a7c0ae7fd53bde9eab3c09a620c23ea
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

[TheHCJ]

1. These permissions were left over from the QR scanner feature and will be removed in a future update

2. The signing key was corrupt so I had to update it with a new one

Hope I cleared things up

[IzzySoft]

1. Thanks! Then I leave it untouched for now.
2. so the original one is "lost", and cannot be used to prove the new one's by the same author? For some background: signing keys are pinned in my repo, to prevent e.g. imposters from pushing their APK as updates; for more details also see How to keep your key safe and what measures to take for the event of loss? So a key change should be verified. Do we have a path to verification here? If the old key cannot be used, your commits are not signed, and no other means of contact was established beforehand (there's no mail address or the like in the metadata here), that would only leave a person-of-trust I guess?

[TheHCJ]

I will update the repo with the old keystore as I have recovered it, I will also make sure to add an email to the metadata

[IzzySoft]

Thanks! There's metadata here (at Github) as well as in my repo. The latter is usually filled when an app enters the repo and then updated when needed, so I'd copy that over once it becomes available.

I don't know how I could verify a keystore, especially if it's broken. Usually I'd ask for an APK built from the same commit as the current one but signed with the old key, as then the signature can be verified and the APKs can be compared (there are tools for that; basically one would "diff" the 2 APKs and there should be no differences except for the signature).

For the future, it would be a good idea to start signing your commits with your very own GPG key. That one is separate from your app's keystore, so the GPG signature can be used to confirm.

[TheHCJ]

Thanks! There's metadata here (at Github) as well as in my repo. The latter is usually filled when an app enters the repo and then updated when needed, so I'd copy that over once it becomes available.

I don't know how I could verify a keystore, especially if it's broken. Usually I'd ask for an APK built from the same commit as the current one but signed with the old key, as then the signature can be verified and the APKs can be compared (there are tools for that; basically one would "diff" the 2 APKs and there should be no differences except for the signature).

For the future, it would be a good idea to start signing your commits with your very own GPG key. That one is separate from your app's keystore, so the GPG signature can be used to confirm.

I'll do that asap

[TheHCJ]

@IzzySoft is there any issues with the release as it seems v3.1.0 it is missing from the repo

[IzzySoft]

Well, scroll up a little: signing key changed; so as the app is pinned to the original signing key in my repo, the update coming signed by another key is rejected. So a transition to the new key is needed, hence updates were disabled until clarified. Which is why I reached out to verify.

No offense meant, but if a third party somehow got access to your Github account here, they could have replaced the APK and act on behalf of you. So how can I verify this didn't happen? As outlined behind above link and my comment. We didn't complete that yet, hence updates are still disabled and that release isn't yet visible in the repo. What options do we have left there? Any of the "top contributors" with direct contact to you who can confirm it's really you and the new key is fine?

The APK currently at the release uses yet another signing key btw:

Signer #1 certificate DN: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Signer #1 certificate SHA-256 digest: 2b141ac3faa79ae644bcbd3d8849735cd60e19f413c8e270f1569f7b822eb3cc
Signer #1 certificate SHA-1 digest: d0fd95e1e31c5c51422052ff5db6f095f44daed1
Signer #1 certificate MD5 digest: 0bad87cdde116aa56eef6c5a7adee6bd
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

Compare the SHA-256 digest of the certificate, it's again different. And that's the important part. Not the DN – anyone can set everything as DN. But the hash would be unique, which is how key changes are detected.

[IzzySoft]

Thanks for chiming in, @j-fbriere! I've noticed the signing key for the app changed. @TheHCJ states
"The signing key was corrupt so I had to update it with a new one" (see start of this thread). As the risk exists that, quoting @TheHCJ again, "my account could of been hacked and you would of pushed a malicious version of my app", in which case the "imposter" would of course also use a similar argument, the last resort for verification is a person knowing @TheHCJ confirming this is no "breach" and the key change is legit. So can you confirm that? Thanks in advance for your help!

[j-fbriere]

I don't think this is a case of "breaching" by an "imposter".
@TheHCJ worked on my own project, Squawker, which is another fork of the same base code as Quacker.
@TheHCJ, who is the developer/owner of the Quacker app, has just restarted his github project recently. Previously when he decided to archive or delete the Quacker github project, maybe he lost the github secrets necessary to sign the app. Now that the Quacker github project is up again, he must have recreated the secrets to sign the app, hence the error.

[IzzySoft]

Thanks for confirming! I'll now go initiating the transition to the new signing key.

[TheHCJ]

Thats fine, I won't change the DN headers as it isn't worth the effort as I have now secured the keystore in my password manager to avoid losing it

[IzzySoft]

Done: v3.1.0 will become available with the next sync around 7 pm UTC. I've also set a notice that the key changed and folks need to uninstall/reinstall to update:

@TheHCJ thanks for starting to sign your commits! That drastically reduces chances for a "hostile take-over" 😃

[IzzySoft]

PS: Please remember…

Permissions are still there, and so is that DEPENDENCY_INFO_BLOCK.

[TheHCJ]

I'm aware the Camera permission will be removed in the next release
(Anyways the app doesn't use the camera so it shouldn't be a major privacy concern!)

[IzzySoft]

People might think it being a concern. So with the permission gone, we no longer give them the idea of doing so 😜

[TheHCJ]

Yh, I would be concerned if I saw that permission aswell so I will try and get v3.2.0 published tommorrow

[IzzySoft]

As you moved the issue here, and I can no longer comment there: Thanks for your reply! As you sign your commits (please make sure to always sign it with your own PGP key, as Github's in this context does mean nothing: had someone taken over your repo they could have signed with Github's key as well), a migration to the new key would be possible. But as you had the repo archived at that point and thus I didn't see a chance for a reply (or any further updates of your app), I have already removed it from the IzzyOnDroid repo. The Readme also no longer carries the IoD badge, so I assume it's OK this way, with your app now available at F-Droid.org?

[TheHCJ]

I am happy with the app being removed from IzzyOnDroid

[IzzySoft]

OK, then we leave it at that. Should you any day want it listed again, you know how to find me 😉 Thanks, and all the best!