AppVerifier's presence on IzzyOnDroid

Question

AppVerifier's presence on IzzyOnDroid

soupslurpr opened this issue a year ago · 25 comments

soupslurpr commented a year ago

@IzzySoft I'd like to request the removal of AppVerifier from IzzyOnDroid.

soupslurpr commented 10 months ago

Amazing!

❤️1

Answer 1 · 2024-01-05T08:43:56.000Z

May I ask why?

Answer 2 · 2024-01-05T08:46:26.000Z

I don't want it to be there because I don't have any control over it.

Answer 3 · 2024-01-05T08:56:56.000Z

Hm, that's strange. The license you've chosen explicitly says

Permission to use, copy, modify, and /or distribute this software for any purpose with or without fee is hereby granted

(emphasis mine).

What kind of control do you need? The way it's presented? That can be done via Fastlane (see my Fastlane Cheat Sheet). Who downloads it? You cannot control this at Github either. What APKs are offered? It's the same ones as here (they are simply picked from what you release here), so only those APKs you've intended to be used.

I mean, I will of course honor your request. I just want to make sure it isn't based on a misunderstanding.

Answer 4 · 2024-01-05T08:58:49.000Z

I don't have any control over IzzyOnDroid at all. What if it one day gets delisted? Then people will be stuck on an outdated version without knowing.

Answer 5 · 2024-01-05T09:17:02.000Z

Same happens when Github closes (or takes your app down). Yes, such things can happen. One day I will be "delisted" myself – which will most likely result in all my sites "going down" shortly thereafter (unless someone takes them over). Should my repo go down one day, people will receive errors in their clients that it can no longer be reached, so they'll have a notification of the event. F-Droid is thinking about implementing app-specific notifications; not sure when those come and what they entail, but I plan to make use of that too where it seems useful (e.g. to inform about a pending delisting).

I've heard a similar argument about 10 years ago for my book server. It's still up and running, for the 13th year now. My repo is up since around 2016, that makes 8 years. I plan to keep it that way.

And with your app only here at Github, people might "be stuck on an outdated version" if they forget to manually check for updates, too 😉

Btw: Delistings in my repo are rare, and usually only happen if an app moved on to F-Droid.org or suddenly no longer meets the inclusion criteria (e.g. as it started to include too many non-free components, trackers, etc – or if its size exceeds the per-app limit (30 MB) too far). I don't see such dangers here; but then, that would be under your control, wouldn't it?

Answer 6 · 2024-01-05T09:19:31.000Z

AppVerifier will be on Accrescent soon which is the only app store that currently meets my requirements for security. Security is another reason.

Answer 7 · 2024-01-05T09:31:07.000Z

For security measures in my repo see here. I doubt Accrescent offers that. I never found out what they really offer – to me they look very nontransparent. When I last checked I couldn't even figure how apps go into their repo, what criteria they have for that, if they stick to FOSS apps or one might accidentally fetch proprietary stuff there (that might have changed since, in which case I stand corrected). And while F-Droid is widely used already (with the option to include 3rd party repos), to my knowledge Accrescent is rather an "enclosed niche" and less known. On a side note: should your app one day disappear from my repo (or my repo disappear entirely), people can seemlessly update from Accrescent then as the signature will match – unless Accrescent is re-signing your APKs.

OK, to not make that a lengthy discussion: If you stick to your decision having the app removed from my repo, this comment was my last try to convince you otherwise. I see your reasoning (though I cannot follow it; a listing on multiple paces is no contradiction, and the license explicitly allows everyone to distribute the app).

So your wish to have it delisted persists?

Answer 8 · 2024-01-05T09:48:02.000Z

For security measures in my repo see here. I doubt Accrescent offers that.

Accrescent offers more then that. It has protection against the server being malicious as the repository metadata is signed (https://accrescent.app/features#signed-metadata) and you don't have to trust on first use as app signing keys are pinned (https://accrescent.app/features#key-pinning).

I never found out what they really offer – to me they look very nontransparent. When I last checked I couldn't even figure how apps go into their repo, what criteria they have for that,

Its in a whitelist only alpha for now, but publishing requirements are at https://accrescent.app/docs/guide/appendix/requirements.html

if they stick to FOSS apps or one might accidentally fetch proprietary stuff there (that might have changed since, in which case I stand corrected).

https://accrescent.app/faq#open-source

And while F-Droid is widely used already (with the option to include 3rd party repos), to my knowledge Accrescent is rather an "enclosed niche" and less known.

It is less known than F-Droid right now.

On a side note: should your app one day disappear from my repo (or my repo disappear entirely), people can seemlessly update from Accrescent then as the signature will match – unless Accrescent is re-signing your APKs.

I understand. And Accrescent does not sign apps itself https://accrescent.app/features#no-remote-signing

OK, to not make that a lengthy discussion: If you stick to your decision having the app removed from my repo, this comment was my last try to convince you otherwise. I see your reasoning (though I cannot follow it; a listing on multiple paces is no contradiction, and the license explicitly allows everyone to distribute the app).

So your wish to have it delisted persists?

Yes.

Answer 9 · 2024-01-05T12:32:07.000Z

OK, removed now (effective with the next sync around 7 pm UTC).

Thanks for the Accrescent details, looks like there really was a lot added since I last checked. Interesting aspects!

the repository metadata is signed […] app signing keys are pinned

Same here. Just no minimum version pinned, nor app name/icon. All else seems to match.

requirements are at accrescent.app/docs/guide/appendix

Differences: No targetSDK requirements here (my repo explicitly supports older devices, and the restrictions/security-measures targeted by that are usually not needed for open-source apps; if you need details on this I can look them up, we had this discussion at another place in the past), no AABs, max app size 30 MB. No specific list of permissions triggering a review (I might adopt that idea, though); no explicit restriction for MANAGE_EXTERNAL_STORAGE (though its abuse would lead to blocking it when detected); currently no check on service intent filters (another good idea I've put on my todo to see if/what from it I can implement here).

Apps do not need to be open-source to be submitted to Accrescent.

OK, that renders it out for me. My repo sticks to FOSS, so people can be sure they only get FOSS and do not accidentally install any proprietary stuff they cannot control (non transparency) and just have to believe what the devs say/promise (as it's impossible to verify if the code is not available).

It is less known than F-Droid right now.

Understandable, given it's much younger and still in alpha. Which is why I wrote "listing on multiple paces is no contradiction" and "people can seemlessly update from Accrescent" (thanks to your links I do know now that they do not sign APKs themselves, so the signature would match).

So as sad as it is having to remove your app, I'm really thankful for the input/insights you provided me to Accrescent. Independent from the stay-or-not-stay of your app in my repo, this also gave me some ideas on possible improvements for my repo.

As outlined, your app is removed now from my repo. Should you re-decide one day and want it back in, just give me a ping. And whatever I adopt from the above, I will outline in the security section of the details link above.

So all the best for you and the future of your app!

Answer 10 · 2024-01-05T20:22:44.000Z

the repository metadata is signed […] app signing keys are pinned

Same here. Just no minimum version pinned, nor app name/icon. All else seems to match.

So in the event of a server compromise people who haven't already downloaded an app won't download malicious versions?

So all the best for you and the future of your app!

Thanks, nice to see that it gave you ideas for improvements for your repo.

Answer 11 · 2024-01-05T21:10:37.000Z

So in the event of a server compromise people who haven't already downloaded an app won't download malicious versions?

In order to place a malicious app on the server, multiple things need to be compromised. E.g. the index is signed, you'd need to rebuild and sign it to get the malicious APK in. And why would a malicious app need to have a lower versionCode? One with a higher versionCode would do as well, and then even affect those already having it installed – provided the signature matches, which would require a second compromised keystore of course. App signing keys are pinned with my repo (with F-Droid.org, only reproducible apps have their keys pinned – with my repo, all apps have).

nice to see that it gave you ideas for improvements for your repo.

Not just ideas, thanks to your explanations and pointers. First stuff is already implemented now (see the ticked check-marks in the linked issue). I'm always open to suggestions. And when they make sense (like in this case) and implementation is possible (only partly here; minVersion pinning would require changes to fdroidserver, which is not under my control or in my capabilities). But thanks to your suggestions, my repo will soon have more protective measures in place F-Droid does not have (up to now, general cert pinning and automated library scans for updates were the only ones).

Answer 12 · 2024-01-05T21:14:20.000Z

So in the event of a server compromise people who haven't already downloaded an app won't download malicious versions?

In order to place a malicious app on the server, multiple things need to be compromised. E.g. the index is signed, you'd need to rebuild and sign it to get the malicious APK in. And why would a malicious app need to have a lower versionCode? One with a higher versionCode would do as well, and then even affect those already having it installed – provided the signature matches, which would require a second compromised keystore of course. App signing keys are pinned with my repo (with F-Droid.org, only reproducible apps have their keys pinned – with my repo, all apps have).

Ah, that's good then.

nice to see that it gave you ideas for improvements for your repo.

Not just ideas, thanks to your explanations and pointers. First stuff is already implemented now (see the ticked check-marks in the linked issue). I'm always open to suggestions. And when they make sense (like in this case) and implementation is possible (only partly here; minVersion pinning would require changes to fdroidserver, which is not under my control or in my capabilities). But thanks to your suggestions, my repo will soon have more protective measures in place F-Droid does not have (up to now, general cert pinning and automated library scans for updates were the only ones).

Awesome

Answer 13 · 2024-01-08T01:10:26.000Z

Short update: checks for flags and intent-filters are already in place now. Checks for permissions will follow later, first I need to deal with the impact of these two. I expect quite a few apps declaring usesCleartextTraffic for valid reasons which need to be marked "allowed", else I'd be drown in too many "alerts" I hardly can manage simultaneously.

I'll see how this goes, probably fine-tune a bit, and then continue with the permission checks once the first "storm" has calmed down. Until now there were only 2 alerts thrown, both "false positives" (a keyboard app declaring the IME intent, and an app to play media from a.o. your local resources which for many people come without SSL had the usesCleartestTraffic probably for exactly this reason.

Answer 14 · 2024-01-12T19:53:03.000Z

Up and working now, including (partial) permission scan. Now I have to fight with the daily reports as each "first update" after implementation might raise a lot of flags, like

! repo/com.machiav3lli.backup_8316.apk declares risky permissions: android.permission.MANAGE_EXTERNAL_STORAGE android.permission.QUERY_ALL_PACKAGES android.permission.READ_SMS android.permission.SEND_SMS android.permission.RECEIVE_SMS android.permission.RECEIVE_MMS android.permission.RECEIVE_WAP_PUSH android.permission.READ_CONTACTS android.permission.READ_CALL_LOG

(as the name suggests, a backup app, so those are justified as needed for backup/restore). Plenty of "upstream issues" opened the last days for unclear ones; again most were justified, a few were scheduled for evaluation if things can be done differently…

Good thing is that ALL of my reports until now which have been replied to have been received well, and in some cases even lead to improvements of the apps (e.g. usesCleartextTraffic was needed in case someone enters local URLs – but one could accidentally have missed the "s" of "https", so with the next update that app will show some "are you sure" whenever it's not "https" (and then remember the URL to not ask again).

With so much cooperation from the app authors, I can really enjoy the progress. Once all is set up and running, with the initial storm having passed (i.e. in a month or so), I'll probably write a blog article on it. Thanks again for the suggestion!

Answer 15 · 2024-01-12T20:58:29.000Z

All your fault! 🤣

Answer 16 · 2024-01-19T09:33:16.000Z

Your suggested enhancements are now fully in place. And believe it or not, I'm adding on top: scanning signing blocks for embedded BLOBs and payloads. Yes, you can embed stuff there, see here. This check is already part of pre-inclusion checks since yesterday. And if you're curious, here's the result for your latest release (verbose output enabled):

Checking AppVerifier-0.6.1.apk ...
  Found 0x7109871a (APK_SIGNATURE_SCHEME_V2_BLOCK; OK)
  Found 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)
  Found 0x42726577 (VERITY_PADDING_BLOCK; OK)
AppVerifier-0.6.1.apk: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

The last line is what will be raised as warning, as it is an "opaque block". Will probably nothing Acrescent is interested in, as they allow fully proprietary apps, too… 🤷‍♂️

Answer 17 · 2024-01-28T00:40:52.000Z

Btw, if you want to get rid of that (I guess you're signing via Android Studio, as apart from that this to my knowledge only happens when Google itself does the signing), here's a snippet for your build.gradle.kts:

android {
    dependenciesInfo {
        includeInApk = false
    }
}

As that BLOB is encrypted with a public key by Google, it's only Google who can read it anyway, so it's of no use to anybody else 😉

That said: All checks are in place now, the last pieces have been deployed a few minutes ago. Only the signature block checks are waiting to be integrated.

Answer 18 · 2024-01-28T00:53:45.000Z

I'm using IntelliJ IDEA Community edition. I found the docs to what you're talking about and yes it seems useless if the app isn't on the Play Store. https://developer.android.com/build/dependencies#dependency-info-play

For disabling when building bundles as well, this code has to be used, per the above docs.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

Answer 19 · 2024-01-28T01:25:23.000Z

Thanks for the additional information! Good to know, adding IntelliJ to the list then as well (developers sometimes ask, so it's good to have the matching hints at hand). Also of course makes sense to mention the AABs explicitly (I didn't as my repo at least currently does not handle those).

Answer 20 · 2024-02-02T17:10:31.000Z

All in place now, see here. Thanks again for all your suggestions!

Answer 21 · 2024-02-02T23:16:00.000Z

Looks good. BTW at the end of the flags section there is a typo "risc".

Answer 22 · 2024-02-03T01:02:07.000Z

Oof. Thanks for spotting that! Even my proof-reader missed that. Fixed now.

Answer 23 · 2024-03-25T01:46:13.000Z

OK, resume is online now: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo, including credits to you (a comparable one, just a little easier for not-so-tech folks, will air in about 5 hours in German at Mike Kuketz' security blog). And now I'll stop nagging you with this topic – just thought I owed it to you to keep you updated about the progress 😉

Answer 24 · 2024-03-25T03:36:59.000Z

Just finished reading it, thanks for the mention! BTW, you definitely were not nagging me, I enjoyed reading the progress updates :)