gokadzev/Musify

android.permission.REQUEST_INSTALL_PACKAGES

IzzySoft opened this issue · 9 comments

My scanner just notified me:

! repo/com.gokadzev.musify_79.apk declares risky permissions: android.permission.REQUEST_INSTALL_PACKAGES

May I ask why a music streaming app needs that permission? Neither the app description nor the README give a clue.

My scanner just notified me:

! repo/com.gokadzev.musify_79.apk declares risky permissions: android.permission.REQUEST_INSTALL_PACKAGES

May I ask why a music streaming app needs that permission? Neither the app description nor the README give a clue.

@IzzySoft Non-Fdroid builds have built-in app updater and using notification click you can install an update, that's why.

https://github.com/gokadzev/Musify/blob/master/lib/main.dart#L310

I see. Is there any other difference between the two builds? Because I have the non-Fdroid version in my repo, as you know. And built-in app updaters are also against the inclusion criteria in my repo, unless they are strictly opt-in and inform about the implications (such updates would bypass all security checks implemented with my repo – not meaning you'd purposely have dangerous stuff in; as you see, if something gets detected I first come here as it could be something you simply didn't notice). So if the updater is the only difference, maybe I should drop that variant from my repo?

I see. Is there any other difference between the two builds? Because I have the non-Fdroid version in my repo, as you know. And built-in app updaters are also against the inclusion criteria in my repo, unless they are strictly opt-in and inform about the implications (such updates would bypass all security checks implemented with my repo – not meaning you'd purposely have dangerous stuff in; as you see, if something gets detected I first come here as it could be something you simply didn't notice). So if the updater is the only difference, maybe I should drop that variant from my repo?

Built-in updates are disabled for the build that's used for fdroid, I'm aware of that requirement of fdroid.

refs:
https://github.com/gokadzev/Musify/blob/master/lib/screens/home_page.dart#L27
https://github.com/gokadzev/Musify/blob/master/lib/screens/more_page.dart#L484

I will also put downloader initialization code in fdroid check condition as I have missed it (But still, both background downloader service and built-in updater are totally unused and inaccessible in fdroid builds).

If the only problem is android.permission.REQUEST_INSTALL_PACKAGES, I can try to find a solution (Such as separate AndroidManifest.xml for fdroid builds or something).

F-Droid to my knowledge currently has no such checks in place for updates, so it doesn't pop up there (and you have disabled the code for the F-Droid build anyway, so there will be a related note there). I ask because the non-fdroid version is in my repo, and the updater is active there. So if the only difference is the self-updater, I'd suggest to remove the app from my repo. Those who prefer using an F-Droid client for updates can get the app from the repo at F-Droid.org. Those who want the built-in updater, can download it once from here and then receive updates that way. I see no reason to have that version in my repo then – or did I miss something?

@IzzySoft

Nevermind... I just realized we're talking about your repository izzydroid

@IzzySoft

I thought we were talking about Fdroid itself and not any specific repository. In this case yes, you can remove Musify from your repo so users will download it from Fdroid and GitHub only.

Let me know your decision to make changes in README according to that tho

Hehe, yeah, can be confusing sometimes – but in the end we're speaking of the same thing now 😄

Yes, I'd remove it here then if you let me know that the badge is gone from your README (we don't want to confuse everyone else with a 404, right?) Thanks!

Hehe, yeah, can be confusing sometimes – but in the end we're speaking of the same thing now 😄

Yes, I'd remove it here then if you let me know that the badge is gone from your README (we don't want to confuse everyone else with a 404, right?) Thanks!

Removed ✅

Thanks! Here too then with the next sync. As that solves the issue, I'm closing it now.