Certificate issue

[IzzySoft]

A scan (see here for details and background) just revealed the APKs at your releases are signed using an expired debug key ("denyAfter 2019-01-01"). As that has security implications, may I ask you to please switch to a proper release key, and provide the corresponding APK signed with it? Thanks in advance!

[IzzySoft]

@nimble0 Any chance? Or did you abandon development of this app?

[nimble0]

I'm taking a look at doing a signed release now.

[nimble0]

I added a signed release: https://github.com/nimble0/dotterel/releases/tag/v0.3.1-dev-signed Let me know if there's anything wrong with it/you need something else.

[IzzySoft]

Thanks @nimble0 – cert looks fine now! However, my (recently improved) scanner also reports the following:

Dangerous Filters:
------------------
android.view.InputMethod

Permissions:
------------
* android.permission.WRITE_EXTERNAL_STORAGE
* android.permission.READ_EXTERNAL_STORAGE
* android.permission.SYSTEM_ALERT_WINDOW
* nimble.dotterel.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

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

I guess IME is clear here (going by the app description, your app serves as input method, right?). But can you give me some explanation on the first 3 permissions (the last one seems to be added to every app now and is unproblematic)? Is the input being read from files (minSdk 16 would then mean there is no SAF, so that would explain the storage permissions). I have however no clue why it would need SYSTEM_ALERT_WINDOW.

As for the dependency info block: I guess you use Android Studio for signing? There should be an option to have it not inject that block I've heard (but don't know where, so I'm happy to be told so I can give proper advice to others). If not, signing with apksigner would avoid that, too. Some background on this can be found here, I'll write up a proper documentation later (already in progress, first draft ready).

Meanwhile, I've replaced the APK in my repo so the initial issue is solved. Leaving this issue here open for the remaining parts. Thanks for your support!

[nimble0]

I guess IME is clear here (going by the app description, your app serves as input method, right?). But can you give me some explanation on the first 3 permissions (the last one seems to be added to every app now and is unproblematic)? Is the input being read from files (minSdk 16 would then mean there is no SAF, so that would explain the storage permissions). I have however no clue why it would need SYSTEM_ALERT_WINDOW.

Yes, Dotterel is an input method.

• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.READ_EXTERNAL_STORAGE

These are for reading/writing to dictionary files which determine how input is translated into text (not a dictionary in the sense of a list of valid words). These are quite user specific so it's preferable that users have easy access to them.

• android.permission.SYSTEM_ALERT_WINDOW

This is used to create overlay dialogs for adding entries to dictionaries or looking up entries in dictionaries. With stenographic input methods it's common to add entries to the dictionary as you use it.

As for the dependency info block: I guess you use Android Studio for signing? There should be an option to have it not inject that block I've heard (but don't know where, so I'm happy to be told so I can give proper advice to others). If not, signing with apksigner would avoid that, too. Some background on this can be found here, I'll write up a proper documentation later (already in progress, first draft ready).

I did use Android Studio to sign it. I don't know where that option would be though.

[IzzySoft]

Yes, Dotterel is an input method.

Thought so. Added this to the allow-list so it doesn't pop up again.

These are for reading/writing to dictionary files

Hm, then maybe I assumed wrong that those permissions are only needed for "lower" Android versions. I can see that SAF would not be ideal here, as that would ask the user to choose a directory so they had to find the right one. But what dictionary files are you talking about there? If they are only used by Dotterel, they should be within the app's scope and thus not need any special permission. If it's the user dictionary. shouldn't that be rather READ_USER_DICTIONARY and WRITE_USER_DICTIONARY then?

SYSTEM_ALERT_WINDOW: thanks, that makes sense. Added to the allow-list now.

I did use Android Studio to sign it. I don't know where that option would be though.

Just got told where today, so maybe you can try if that works for you, too. The pointer I got to the official documentation says it's in build.gradle.kts (so that was for Kotlin; not sure if it works for build.gradle as well so I'd appreciate if you could try it and let me know: if you make the resulting APK available to me I can check):

android {
    dependenciesInfo {
        includeInApk = false
    }
}

[nimble0]

Hm, then maybe I assumed wrong that those permissions are only needed for "lower" Android versions. I can see that SAF would not be ideal here, as that would ask the user to choose a directory so they had to find the right one. But what dictionary files are you talking about there? If they are only used by Dotterel, they should be within the app's scope and thus not need any special permission. If it's the user dictionary. shouldn't that be rather READ_USER_DICTIONARY and WRITE_USER_DICTIONARY then?

The dictionaries are kind of Dotterel specific, but they can be used with Plover, which runs on desktops. This makes cloud storage a good place for them. The dictionary files are also easily editable JSON files so I want the user to be able to access them.

A system joins together multiple dictionaries (and some other things). This is the built-in system: https://github.com/nimble0/dotterel/blob/38eec408d90de3cceff48e1c1f996fad0e967037/app/src/main/assets/systems/ireland.english.json

I think the reason I added file system support is so that a system and its dictionaries could be imported in a single step, with the dictionaries as relative paths. With content providers, each dictionary file would have to be manually resolved.

Just got told where today, so maybe you can try if that works for you, too. The pointer I got to the official documentation says it's in build.gradle.kts (so that was for Kotlin; not sure if it works for build.gradle as well so I'd appreciate if you could try it and let me know: if you make the resulting APK available to me I can check):

I added a build with that option: https://github.com/nimble0/dotterel/releases/download/v0.3.1-dev-signed/dotterel-v0.3.1-dev-signed2.apk

[IzzySoft]

The dictionaries are kind of Dotterel specific …

Thanks! Added explanations to read+write, putting both on the "allow-list"

I added a build with that option

And you've been successful: the BLOB is gone, thanks!

All done then, closing the ~door~ issue now.