F-Droid Release about shiori-android-client

[DesarrolloAntonio]

Finally I've removed the 'MANAGE_EXTERNAL_STORAGE', thanks for the advice

[DesarrolloAntonio]

I have updated the AGP and some libraries, I assume one of the libraries must have added it. I will check to see what has happened."

[IzzySoft]

I could even check to include it with my repo – but as long as the APKs are signed with debug keys that won't be possible:

Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: b0724d3e750bb7d737cda8d881480ed189d87c84ac66fb7e9c8632c0dce5c797
Signer #1 certificate SHA-1 digest: 437fb08422a5254032a6c014b774addec912d245
Signer #1 certificate MD5 digest: fb434487f1f5666376c4465441fbad01
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

See:

• Why debug certificate is not safe to sign android APKs?
• issues when using local debug keystore

Could you please sign the APKs at releases/ with a release key? Thanks in advance!

[DesarrolloAntonio]

You're right, I must have a bug in my GitHub Actions file, I'll fix it as soon as I can.

[DesarrolloAntonio]

Fixed, the apk now is signed with release key

[IzzySoft]

Thanks Antonio, that looks good! Preparing the integration here now. Meanwhile, from the output of my scanners:

No offending libs found.


Dangerous flags:
----------------
* usesCleartextTraffic

Permissions:
------------
* android.permission.INTERNET
* android.permission.WRITE_EXTERNAL_STORAGE
* com.desarrollodroide.pagekeeper.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
* android.permission.READ_EXTERNAL_STORAGE*

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

• "No offending libs found": so no proprietary, tracking etc. libs detected – all fine there 🥳
• usesCleartextTraffic: I guess this is intended for "local resources" (i.e. self-hosted in the LAN, where it's hard to have proper SSL certs)?
• Storage Permissions: is there some export/backup functionality, or what is that needed for?
• DEPENDENCY_INFO_BLOCK: this one is easily fixed:

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.

---

Nothing of the above is a show-stopper here (I'm integrating your app with my repo now). But for transparency, these questions would be good to have clarified (and of course the blob removed, if possible). So if you could help with those details I'd include them then.

Thanks a lot!

[IzzySoft]

OK, there you go:

That looks fine so far (metadata where imported from your PlayStore listing). For some background to above questions:

So once above questions are answered, I can fill those gaps and the "chocolate" goes away, showing the proper explanations instead.

Your app will become available here around 7 pm UTC, with the next sync. Those having my repository configured with their favorite F-Droid client will automatically be able to access it from there as well. If you like what you see there, be welcome to pick a badge to link there e.g. from your README 😃

[DesarrolloAntonio]

Thank you very much for your work.

I use WRITE_EXTERNAL_STORAGE to be able to download the EPUB and then share it.
usesCleartextTraffic is set to true in case Shiori is installed on a server that does not have SSL. For my tests, I use the following URL: http://144.24.183.231:8086/
DEPENDENCY_INFO_BLOCK, I have modified build.gradle so that the Google metadata does not appear, it will be fixed in the next release.

[IzzySoft]

I use WRITE_EXTERNAL_STORAGE to be able to download the EPUB and then share it.

Which EPUB? I thought this is a bookmark app?

usesCleartextTraffic

Thanks, I've set that accordingly then.

DEPENDENCY_INFO_BLOCK

Great, thanks!

[DesarrolloAntonio]

Which EPUB? I thought this is a bookmark app?

Shiori has the ability to save the content of bookmarks, one option is to save it as Epub.

[IzzySoft]

Ah, now I get it, thanks! But if it's just for this one file, why not using SAF (Storage Access Framework) and let the user pick a location? SAF was introduced with Android 5, which is the minimal version your app supports. It has its culprits and complexities, true – but for saving/reading a single file it should be fine. Your app the wouldn't need to declare a single storage permission.

[DesarrolloAntonio]

SAF

I can't use SAF because the epub is not public, to download it, I need authorization via a sessionID that is sent in the headers.

[IzzySoft]

So where do you store the EPUB then? If it is inside your own application's scope, you won't need any storage permissions either. If not, I don't see what difference SAF makes in this context.

But OK, you will know better than me what is needed. I've set the explanations accordingly. Thanks!

[DesarrolloAntonio]

I'm using the Downloads folder
val directory = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS)

[DesarrolloAntonio]

So where do you store the EPUB then? If it is inside your own application's scope, you won't need any storage permissions either. If not, I don't see what difference SAF makes in this context.

But OK, you will know better than me what is needed. I've set the explanations accordingly. Thanks!

But you're right, I'll change the storage location to be within the app's scope and remove the permission.

[IzzySoft]

I'm using the Downloads folder

Oww… that one is special fun with SAF over Android versions, requiring a different permission with every second Android version… well, almost. Will need MANAGE_EXTERNAL_STORAGE starting at some point.

But you're right, I'll change the storage location to be within the app's scope and remove the permission.

If it should be private anyway, good idea. An export can always be offered, be it via share or SAF then.

[IzzySoft]

But with today's update, we have some new permission alerts:

! repo/com.desarrollodroide.pagekeeper_22.apk declares sensitive permission(s):
  android.permission.READ_PHONE_STATE android.permission.READ_EXTERNAL_STORAGE

What happened, and what are they needed for? Dragged in by one of the new dependencies?

[DesarrolloAntonio]

But with today's update, we have some new permission alerts:

! repo/com.desarrollodroide.pagekeeper_22.apk declares sensitive permission(s):
  android.permission.READ_PHONE_STATE android.permission.READ_EXTERNAL_STORAGE

What happened, and what are they needed for? Dragged in by one of the new dependencies?

When updating the Android Gradle Plugin, it seems necessary to set the minSdkVersion in all modules to prevent the addition of those permissions:

• READ_PHONE_STATE
• READ_EXTERNAL_STORAGE

This is the log of the manifest-merger:

1.0.0/AndroidManifest.xml:20:5-44
android:targetSdkVersion
INJECTED from /home/ubuntu-dev/Dev/My Projects/Shiori/presentation/src/main/AndroidManifest.xml
android:minSdkVersion
INJECTED from /home/ubuntu-dev/Dev/My Projects/Shiori/presentation/src/main/AndroidManifest.xml
uses-permission#android.permission.WRITE_EXTERNAL_STORAGE
IMPLIED from /home/ubuntu-dev/Dev/My Projects/Shiori/presentation/src/main/AndroidManifest.xml:2:1-63:12 reason: com.desarrollodroide.model has a targetSdkVersion < 4
uses-permission#android.permission.READ_PHONE_STATE
IMPLIED from /home/ubuntu-dev/Dev/My Projects/Shiori/presentation/src/main/AndroidManifest.xml:2:1-63:12 reason: com.desarrollodroide.model has a targetSdkVersion < 4
uses-permission#android.permission.READ_EXTERNAL_STORAGE
IMPLIED from /home/ubuntu-dev/Dev/My Projects/Shiori/presentation/src/main/AndroidManifest.xml:2:1-63:12 reason: com.desarrollodroide.model requested WRITE_EXTERNAL_STORAGE

[IzzySoft]

Good find! Yes, I remember that some permissions are automatically implied based on targetSdk (see here. I knew that for READ_EXTERNAL_STORAGE if WRITE_EXTERNAL_STORAGE is present. I knew this for RED_CALL_LOG and WRITE_CALL_LOG with targetSdk < 16. I must have skipped that one as, well, how likely is a targetSdk < 4? Funny that the new AGP assumes that as default, with the toy shop requiring an ever higher one – and that it now adds them to the manifest (before they were just applied "on device"). OTOH, good it's now made transparent.

Good to see this resolved, thanks!