Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on permissions #30

Open
IzzySoft opened this issue Dec 1, 2024 · 2 comments
Open

Question on permissions #30

IzzySoft opened this issue Dec 1, 2024 · 2 comments

Comments

@IzzySoft
Copy link

IzzySoft commented Dec 1, 2024

Our scanners at IzzyOnDroid were just triggered by the new release, and report:

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

I assume the storage permission is to read audio files from whereever on local storage they are located (but what's the WRITE part for then?)? As for DEPENDENCY_INFO_BLOCK, that can easily be avoided with a small addition to your build.gradle:

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. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Thanks in advance!

@msimonides
Copy link
Owner

msimonides commented Dec 1, 2024

The permission is part of legacy support that could be cleaned up with a bit of care not to break existing installations.
However, I am no longer working on this project. The version I have pushed recently is actually from Sep 2023...
Therefore I won't be updating the permissions, sorry.

You may consider removing the app from your repository. The app will continue to work but I expect very few new users. Existing users are likely to install via QR code provisioning anyway.

Some more context:
The app was created with support for external storage only. Since then it was updated to use the modern storage permissions (SAF). However for existing installations there's a compatibility mode that sticks to the old ways (less relevant today, but it was crucial those 2-3 years ago).

The app allows downloading a few sample files so that new users can test it without configuring folders, hence the write permission - the old versions were downloading to external storage where the user could see the files and replace with their own.

@IzzySoft
Copy link
Author

IzzySoft commented Dec 1, 2024

The permission is part of legacy support that could be cleaned up with a bit of care not to break existing installations.
However, I am no longer working on this project. The version I have pushed recently is actually from Sep 2023...
Therefore I won't be updating the permissions, sorry.

Thanks! Added the explanation then.

You may consider removing the app from your repository. The app will continue to work but I expect very few new users.

No prob. If you want me to remove it, I will of course do so. It can also stay until it's reported "no longer working" (or until you request removal later), up to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants