Question on permissions

[IzzySoft]

My scanner today reported after processing the recent release's APK:

! repo/cgeo.geocaching_20240319.apk declares flag(s): usesCleartextTraffic
! repo/cgeo.geocaching_20240319.apk declares sensitive permission(s):
  android.permission.READ_EXTERNAL_STORAGE android.permission.ACCESS_FINE_LOCATION
  android.permission.ACCESS_COARSE_LOCATION android.permission.READ_CONTACTS
! repo/cgeo.geocaching_20240319.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Can you please clarify…

• what cleartext connections are used and where to?
• what those permissions are needed for (location seems pretty clear for a GeoCaching app of course, but the others are not)?

The DEPENDENCY_INFO_BLOCK can be easily avoided 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.

[moving-bits]

For a quick overview on requested permissions, please have a look at our manual: https://manual.cgeo.org/de/installation#permissions (slightly outdated, though). A new permission is "read contacts" due to integration of c:geo contacts platform, and only requested on demand if the user starts a feature regarding contacts.

With regard to "cleartext connections" I can only guess: c:geo accepts a couple of links, eg: a url to a gpx file, and accepts unencrypted (http) connections for it (besides accepting https connections).

READ_EXTERNAL_STORAGE is only required for older Android version, for newer versions c:geo is using SAF (storage access framework).

[bekuno]

For the cleartext entry I searched a bit in the code and found in AndroidManifest.xml:

    <application
        ...
        android:usesCleartextTraffic="true"

This was introduced for Issue #7889. For details see there. In short:

Failure (1 ms) GET http://img.geocaching.com/cache/large/681ebcbd-f446-4f23-8327-82801195421d.jpg (java.net.UnknownServiceException: CLEARTEXT communication to img.geocaching.com not permitted by network security policy)

The jpg had integrated text and was downloaded with http.

The images at geocaching.com should in the meantime downloadable with https, but probaly there are links (also at other platforms) to http sources.

[fm-sys]

cleartext

Cgeo supports many different platforms. While most of them support https meanwhile, this doesn't apply to all sites.

E.g. http://gcvote.com/ is http only. (while the front end is broken, their Api is still working.)

Same applies to embedded images inside geocache listings which may be hosted on third party servers. We have no control over that.

We already use https where possible.

DEPENDENCY_INFO_BLOCK

Is this any problem? If yes, we would be happy to see a PR fixing this.

---

Only the contacts permission is new BTW and was introduced cause we merged the cgeo contacts plug-in with the main app to reduce maintenance effort and make the feature more popular.

[IzzySoft]

please have a look at our manual

Thanks! That answers the storage permissions, added here.

android.permission.ACCESS_FINE_LOCATION: needed to locate/guide-to GeoCaches
android.permission.ACCESS_COARSE_LOCATION: needed to locate/guide-to GeoCaches
android.permission.READ_EXTERNAL_STORAGE: needed on lower Android versions to read  geocaches saved for offline use
android.permission.WRITE_EXTERNAL_STORAGE: needed on lower Android versions to save geocaches for offline use
android.permission.READ_CONTACTS: used optionally for integration of the c:geo contacts platform

cleartext

OK, got it. Are there at least any warnings shown? Plain http can easily be MITM'd and thus poses a risk.

(DEPENDENCY_INFO_BLOCK) Is this any problem?

As outlined. It's an opaque blob only Google can read (as it's encrypted with their key), so nobody can tell for sure what's really in there. An article on this topic will be published on Monday, going a bit more in-depth on the risks of those "dependency block blobs" (there are others, too).

If yes, we would be happy to see a PR fixing this.

Scroll up, it's basically a one-line fix in your build.gradle. As you publish your app on Play as well, you might wish to only apply it to APKs (so the AABs you upload to PlayStore keep the blob, in case Google demands it). So basically insert the above in here as e.g.

    dependenciesInfo {
        includeInApk = false
    }

That's all.

[bekuno]

For backgrounds to the DEPENDENCY_INFO_BLOCK see https://gitlab.com/fdroid/admin/-/issues/367 (https://gist.github.com/obfusk/31c332b884464cd8aa06ce1ba1583c05#dependency-info-block-1).
We do not have a dedicated buildType/sourceSet for F-Droid.

Description:
https://developer.android.com/build/releases/past-releases/agp-4-0-0-release-notes#dependency-metadata

[bekuno]

(DEPENDENCY_INFO_BLOCK) Is this any problem?

As outlined. It's an opaque blob only Google can read (as it's encrypted with their key), so nobody can tell for sure what's really in there. An article on this topic will be published on Monday, going a bit more in-depth on the risks of those "dependency block blobs" (there are others, too).

I understand on one side, that a salted encrypted text is not deterministic and therefor the apk is no more deterministic.
But as a apk is only a container, the salted encryption of this text file is a good idea.

Of course, I can see that F-Droid neither needs nor can use this encrypted package.

If yes, we would be happy to see a PR fixing this.

Scroll up, it's basically a one-line fix in your build.gradle. As you publish your app on Play as well, you might wish to only apply it to APKs (so the AABs you upload to PlayStore keep the blob, in case Google demands it).

Currently we build no Bundle, so your idea would not solve the problem.

It would be fine if you could create a PR for dedicated sourceSets (nightly/release) for F-Droid.

[IzzySoft]

It would be fine if you could create a PR for dedicated sourceSets

Sorry – but not being an Android dev myself, I cannot do that. I can only give hints from what I know, which I did here. But thanks for picking this up!

Btw: if it were intended as transparent help, the blob would not have been encrypted with Google's public key, but rather signed with it. Signing would guarantee it cannot be tampered, while still being transparent about what's inside. So skepticism arises from the fact of stuff being hidden from the public view here. Including dependency details would be very welcome if it were done transparently, but not if it's done opaque. What is it the public should not see? What in that blob must be kept secret, and why? We're talking open source here.

[fm-sys]

Are there at least any warnings shown? Plain http can easily be MITM'd and thus poses a risk.

No warning is shown. But I think the risk is rather low. We make an Api call to gcvote to request the rating (number between 0-5). If it gets MITM'd, our regex will either fail or display a wrong rating for a cache. Same applies for uploading a MITM'd rating. Pretty limited risk IMHO.

Platforms especially with sensitive login data of course should and are using https.

[bekuno]

Btw: if it were intended as transparent help, the blob would not have been encrypted with Google's public key, but rather signed with it. Signing would guarantee it cannot be tampered, while still being transparent about what's inside. So skepticism arises from the fact of stuff being hidden from the public view here. Including dependency details would be very welcome if it were done transparently, but not if it's done opaque. What is it the public should not see? What in that blob must be kept secret, and why? We're talking open source here.

Sorry, I have to disagree here. We are not talking about open source here, but about Android software regardless of where the source code is held.
There is no way to circumvent the encryption of this sensitive information.

This information must be encrypted because an attacker could easily use it to attack the software. Of course, he could scan the source code if it is accessible to the whole world (as with c:geo). But this is more complicated than using information that is directly in the software (if it were integrated and readable there).

[bekuno]

cleartext

OK, got it. Are there at least any warnings shown? Plain http can easily be MITM'd and thus poses a risk.

In your screenshot it is stated that "the purpose has not clarified"

Will the scanner look for a special point (in code or a reference) or do you have to anotate this manually?

The geocaching cache descriptions can use external links. In this was we do not have control, if it is http or https.
(Btw., this was one of the reason, why geocaching.com changed the policy that no external links are allowed anymore.)

[IzzySoft]

But I think the risk is rather low.

So what would you suggest to add as explanation there?

In your screenshot it is stated that "the purpose has not clarified"

Which is what we're currently doing (clarifying). And once done, yes, it's annotated manually. I'm not aware of any safe method to automate this. So what you see there is the default text when no annotation was yet made.

The geocaching cache descriptions can use external links. In this was we do not have control

That's right – and you're not the only ones with this. Another app having a similar issue decided to show a warning hint when encountering a cleartext link – once per server addressed, then remember the decision made (in case it was chosen to continue with that URL, like "risks explicitly accepted"). I cannot tell if that's feasible here, hence I only raise the question. I'm open to your suggestion for the annotation.

We are not talking about open source here

Oh, we do: my repo only accepts open source apps (as does F-Droid.org).

There is no way to circumvent the encryption of this sensitive information.

Ugh? What's "sensitive" here? I can (partly) understand this with closed source, but even there I can extract most of those details (which libraries are used etc) – guess how it comes that those are shown in my repo (see the "79 libraries detected" in above screenshot).

This information must be encrypted because an attacker could easily use it to attack the software.

With open source, wouldn't that be accomplished much easier and more detailed by simply accessing the source repo? As for closed source: a choice could be offered to optionally encrypt it. So make it "encryption opt-in" instead of "all or nothing".

[bekuno]

But I think the risk is rather low.

So what would you suggest to add as explanation there?

In your screenshot it is stated that "the purpose has not clarified"

Which is what we're currently doing (clarifying). And once done, yes, it's annotated manually. I'm not aware of any safe method to automate this. So what you see there is the default text when no annotation was yet made.

The geocaching cache descriptions can use external links. In this was we do not have control

That's right – and you're not the only ones with this. Another app having a similar issue decided to show a warning hint when encountering a cleartext link – once per server addressed, then remember the decision made (in case it was chosen to continue with that URL, like "risks explicitly accepted"). I cannot tell if that's feasible here, hence I only raise the question. I'm open to your suggestion for the annotation.

You can take my text above.

Interesting idea to include such warning. I will create an issue for it.

We are not talking about open source here

Oh, we do: my repo only accepts open source apps (as does F-Droid.org).

No. You are talking about F-Droid.
We are talking about c:geo and different stores, but mainly about Google Play.

There is no way to circumvent the encryption of this sensitive information.

Ugh? What's "sensitive" here? I can (partly) understand this with closed source, but even there I can extract most of those details (which libraries are used etc) – guess how it comes that those are shown in my repo (see the "79 libraries detected" in above screenshot).

Do you also see witch version they have?

This information must be encrypted because an attacker could easily use it to attack the software.

With open source, wouldn't that be accomplished much easier and more detailed by simply accessing the source repo? As for closed source: a choice could be offered to optionally encrypt it. So make it "encryption opt-in" instead of "all or nothing".

Do you see the repository name in the apk?
How easy would it be to find the correct repo (and e.g. not an outdated fork) for every open source software?

Once more, we are talking about the Google Play store.
Google states here https://support.google.com/googleplay/android-developer/answer/10358880 about this information.

Make the encryption optionally would probaly be fine for us (and F-Droid), but this is not in our hand.

[IzzySoft]

You can take my text above.

I'm a bit limited concerning the length of the text there. Does the following look OK to you?

Interesting idea to include such warning. I will create an issue for it.

Thanks a lot!

No. You are talking about F-Droid.
We are talking about c:geo and different stores, but mainly about Google Play.
Once more, we are talking about the Google Play store.

Hm, I thought I was the one opening this issue, and asking about this. I'm not concerned about PlayStore at all: this entire blob is only useful for PlayStore. I'm totally fine with you including it with what you ship there – I was rather suggesting to not ship it here (or rather, to ship an APK without it here – again no problem if both would be available and easy to distinguish). It does not help anybody apart from Google. For everyone else, it's just an opaque blob which might just contain the dependency tree, but also could contain pretty much anything else; we cannot verify. You could even use its block ID (0x504b4453) and put something entirely different in there. Or someone else could do that (before you ask: no, that would not invalidate the signature, we've tested that in more than one POC). So for everyone except Google (who can decode it), this could pose a security risk. Otherwise I would not be pushing on it so hard 😉

Google states here

And you can verify that? I remember Google once stated if you turn location logging off they would not collect it. In case you don't remember that (as it was several years ago), this was not the truth; they still collected it. So if they state something, I prefer having a way to validate that. And even then, as pointed out, anyone could just abuse that block to put in their own stuff – and again, only Google could tell.

Make the encryption optionally would probaly be fine for us (and F-Droid), but this is not in our hand.

OK. But what is in your hand is which variant you ship to Google, and which you provide here 😉 So may I kindly ask you to provide an APK without it, for the FOSS world? And I'm not asking for F-Droid here, but for my repo, where your app is currently listed (since 2016-08-09 btw, so for almost 8 years now) – F-Droid doesn't have it (at least not as cgeo.geocaching). Thanks in advance!

[fm-sys]

this could pose a security risk

Imagine I take the APK and swap the blob to something else. How would this affect users security? To me that blob sounds like a dead block of bytes which can and will not get executed on the device.

The question is whether it's possible to convert your POC into an exploit?! Otherwise it's not a security issue in any way...

[bekuno]

You can take my text above.

I'm a bit limited concerning the length of the text there. Does the following look OK to you?

Ok, that's fine, imho.

Interesting idea to include such warning. I will create an issue for it.

Thanks a lot!

Done, see #15497.

No. You are talking about F-Droid.
We are talking about c:geo and different stores, but mainly about Google Play.
Once more, we are talking about the Google Play store.

Hm, I thought I was the one opening this issue, and asking about this.

Sorry, but this issue is talking about the c:geo apk permissions.

I'm not concerned about PlayStore at all: this entire blob is only useful for PlayStore. I'm totally fine with you including it with what you ship there – I was rather suggesting to not ship it here (or rather, to ship an APK without it here – again no problem if both would be available and easy to distinguish).

The project provides his work in this repo.
You can build your own apk, if necessary, because the project is open source with a Apache-2.0 license, see https://github.com/cgeo/cgeo/blob/master/LICENSE .

It does not help anybody apart from Google.

If we believe that these are the sdkDependencies - then we have a use case, not google (besides their reputation).

For everyone else, it's just an opaque blob which might just contain the dependency tree, but also could contain pretty much anything else; we cannot verify. You could even use its block ID (0x504b4453) and put something entirely different in there. Or someone else could do that (before you ask: no, that would not invalidate the signature, we've tested that in more than one POC).

Then you can remove it for your copy of c:geo, is't it?

So for everyone except Google (who can decode it), this could pose a security risk. Otherwise I would not be pushing on it so hard 😉

Google states here

And you can verify that? I remember Google once stated if you turn location logging off they would not collect it. In case you don't remember that (as it was several years ago), this was not the truth; they still collected it. So if they state something, I prefer having a way to validate that. And even then, as pointed out, anyone could just abuse that block to put in their own stuff – and again, only Google could tell.

There is nothing without a bit of trust.
And the reason looks ok.

Make the encryption optionally would probaly be fine for us (and F-Droid), but this is not in our hand.

OK. But what is in your hand is which variant you ship to Google, and which you provide here 😉 So may I kindly ask you to provide an APK without it, for the FOSS world? And I'm not asking for F-Droid here, but for my repo, where your app is currently listed (since 2016-08-09 btw, so for almost 8 years now) – F-Droid doesn't have it (at least not as cgeo.geocaching). Thanks in advance!

I am also sceptical about many things that Google does.
But it's too easy to say: Google != FOSS.

Btw., It is fine that you have such a repository.
Can you update the c:geo images there, they are totally outdated.

Maybe someone has time and is interested in building a google-reduced c:geo ("F-Droid") - the issue #15493 would be the starting point.

[IzzySoft]

@fm-sys

To me that blob sounds like a dead block of bytes which can and will not get executed on the device.

Not quite. My blog article on that is not yet published (I hope to have it ready next week). But you could search for MEITUAN_APK_CHANNEL, which gives an example of such a block being used for payload. I'm neither a developer nor a security expert, so please forgive me not being able writing an exploit for that. For a vector, consider that each app can read its own APK (to extract the payload) – and IIRC it doesn't need "high privileges" to read other APKs (there are apps to extract APKs of installed apps to confirm this). So were I a malicious actor with the means to, I could possibly hide my malicious content in your APK and provide my "executor" as innocent second APK.

@bekuno

Ok, that's fine, imho.

Thanks! In place then.

Done, see #15497.

Wonderful, thanks! 🤩

Sorry, but this issue is talking about the c:geo apk permissions.

So shall I split this part off to a separate issue? Or would it suffice to update the title, as my initial post clearly covers the other questions as well? 😉 (Edit: see the end of this comment – I see this topic moved to another issue already)

You can build your own apk

As I've said already, I'm no developer. I don't have any build environment even. And even if I had, I'd have to sign it with a different key (so to avoid confusion, I'd have to use a different applicationId) – and it would require me to permanently keep up with your code/releases and repeat the action, which I don't have the resources to. While for you (forgive me should I over-simplify because of not fully understanding the details) it would just mean copying the unsigned APK and sign both copies differently, if you'd wish to keep that blob in one.

Then you can remove it for your copy of c:geo, is't it?

If I had the technical means for it, probably. It was tried and seemed to work – but I don't remember why that approach was abandoned. For one, I'd decide against it as I clearly state to provide the developers' APKs unaltered – and even removing this would mean altering the APK, though the signature verification would not break. A simple diff would show that. And I'm not one who states A but does B – so I stand to my word of shipping the APKs unaltered. Would I break that promise once, even "for a good purpose", I'd break trust. How much could you trust my other statements then?

But it's too easy to say: Google != FOSS.

Nope, that's stating a fact, sorry. Ever checked what happened to AOSP over the years? Especially to its apps? What happened to mail, calendar & co? They got abandoned, replaced by non-FOSS Google apps. Without your wanting it, things drag in non-free dependencies (that play-services-oss-licenses e.g. drags in GMS, which definitely is not FOSS).

But we're heading quite into some other arguments here. I'm not here to fight you 😉 I'd really appreciate if you could provide an APK without that blob – but in the end will also accept a "no" if you really don't want it. Especially as that would be arguing about a needle, while with GMS and Google Maps there're some knives present, too 😜

Can you update the c:geo images there, they are totally outdated.

Gladly, if you point me to replacements! One possibility would eg be to have Fastlane structures here in the repo (just the metadata, no binaries needed though you probably could use those for deployment to PlayStore then) – see my Fastlane Cheat Sheet for some guidance if you wish. My updater would then not fetch only the APK, but see to keep screenshots, description, changelogs, icon – whatever you put into Fastlane – in sync as well. If you want me to, I could send a "starter package" with those metadata via PR, which you could then build upon. But of course you could simply point me to some replacements whenever needed. If you want, also an updated app description 😉

Maybe someone has time and is interested in building a google-reduced c:geo ("F-Droid") - the issue #15493 would be the starting point.

Thanks! And agreed, let's move that part of my initial question over there. Maybe someone even might offer a flavor replacing other proprietary pieces (e.g. Maps by OSM), for a "more-foss" build 😉

Thanks a lot for your support, much appreciated!

[fm-sys]

Screenshots can be found here:

https://github.com/cgeo/cgeo/tree/master/main/project/playstore/screenshots

We can move them into fast lane structure though, if that makes it easier on the long run...

[IzzySoft]

Screenshots can be found here:

Thanks! Updated, and also added the German ones. As I saw them there, I've also updated the app description. Changes will become visible with the next sync around 7 pm UTC.

We can move them into fast lane structure though, if that makes it easier on the long run...

Having them in Fastlane would make automation possible, as outlined – so there'd be no need to wait for manual action on my end (unless something needs replacement before the next version is released, in which case I'd need to manually trigger a sync).

[bekuno]

We can move them into fast lane structure though, if that makes it easier on the long run...

Having them in Fastlane would make automation possible, as outlined – so there'd be no need to wait for manual action on my end (unless something needs replacement before the next version is released, in which case I'd need to manually trigger a sync).

Fastlane -> "fastlane screenshots for Android" looks very interesting, see https://docs.fastlane.tools/getting-started/android/screenshots/

[IzzySoft]

Yeah, if you're OK using the binaries, you can automate quite a few things. Up to publishing at PlayStore & Co. Catching 2 birds with 1 breadcrumb, so to say 😉