Question on flags

[IzzySoft]

The APK at your latest release is compiled for debug, and has the usesCleartextTraffic. Could you please provide a release build – and either remove the usesCleartextTraffic or clarify why it's needed? Thanks in advance!

[pbsurf]

I assume by "compiled for debug", you mean that android:debuggable = true. This is done for convenience - so I don't need to deal with multiple builds and can debug problems on my device without installing a different build. The binary itself is a "release" build (-O2 optimization, symbols stripped).

usesCleartextTraffic is needed because not all tile servers support https

[IzzySoft]

Yes, I meant android:debuggable = true – which is not intended for distribution as it also has security implications. Which is why at the IzzyOnDroid repo, we do not accept such APKs (I was looking to integrate your app there). The explanation for usesCleartextTraffic is totally fine, we'd just make this transparent then.

[IzzySoft]

Another point is the signing key used:

Number of signers: 1
Signer #1 certificate DN: O=Stylus Labs, L=Mountain View, ST=CA
Signer #1 certificate SHA-256 digest: 10c6776d7f16a4e5979721e5ef233310f5438b924643f632809f65471761a98c
Signer #1 certificate SHA-1 digest: 25a4314dd170c3815397d2d6a910c9f3f7b6fa05
Signer #1 certificate MD5 digest: 117339acbd2f8e148f368d815bfe57ca
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 1024
Signer #1 public key SHA-256 digest: e488a569cf1a0f609f67f17a4b0459f8391644d995aa3860cc8c6a15bb9e7a74
Signer #1 public key SHA-1 digest: 64bcbebf9e3d12a6e18cf30495e66085eed93cae
Signer #1 public key MD5 digest: 91477f66f3f6aad38cce70d462077c92
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 1024-bit RSA key (weak)
The certificate uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
The certificate uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.

SHA1withRSA + 1024-bit RSA is double-weak combination. As the comment suggests, it's just a matter of time when this will no longer be accepted by Android itself. Convenience is one thing, but this is a security question.

usesCleartextTraffic is acceptable in this case, as you outlined why it's needed. But debug + weak key, that's not for distribution. It might be OK for "local test versions", but APKs for distribution should be compiled for release and protected with a stronger key.

So no bad feelings, but for my orientation: do you plan to change that – or should I strike Maps from my watch-list (and stop bothering you)?

[pbsurf]

Created a new release with APK using SHA384withRSA + 4096-bit key. I'm planning to look into using Github actions or something to automate builds so adding a build with debuggable=false would be straightforward. I can update this thread at that time.

[IzzySoft]

Certificate looks fine now, thanks! Just waiting for debuggable=false then.

[pbsurf]

Sorry for the delay! The latest release has debuggable=false now: https://github.com/styluslabs/maps/releases/download/v1.0-rc6/ascend-700cab3.apk

[pbsurf]

Updated link: https://github.com/styluslabs/maps/releases/download/v1.0-rc6/ascend-android-700cab3.apk

[IzzySoft]

I've noticed; the original APK disappeared in the middle of a run here 🙈

I tried to build, but obviously I miss some dependencies:

make: /home/runner/android-sdk/ndk/26.3.11579264/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++: No such file or directory

My build recipe (we use rbtlog for Reproducible Builds here, see e.g. Reproducible Builds, special client support and more at IzzyOnDroid):

---
repository: https://github.com/styluslabs/maps.git
updates: releases
notes:
  - find JDK, NDK, cmake etc. versions in app/android/gww
versions:
  - tag: v1.0-rc6
    apks:
      - apk_pattern: ascend.*\.apk
        apk_url: https://github.com/styluslabs/maps/releases/download/v1.0-rc6/ascend-android-700cab3.apk
        build:
          - sdkmanager --sdk_root=/usr/local/lib/android/sdk --install 'platform-tools'
          - sed -r '/signingConfigs.debug/d' -i app/android/app/build.gradle
          - cd app/android
          - git clone https://codeberg.org/IzzyOnDroid/gradlew.py
          - gradlew.py/gradlew.py -v assembleRelease -Papp_versioncode=$(git tag -l | wc -l) -Papp_versionname=$(git describe --tags)
          - find . -name '*.apk'
          - mv app/build/outputs/apk/release/*unsigned.apk /outputs/unsigned.apk
        build_cpus:
        build_home_dir: /home/runner
        build_repo_dir: /home/runner/work/maps/maps
        build_timeout:
        build_user: runner
        provisioning:
          android_home: /usr/local/lib/android/sdk
          build_tools: 34.0.0
          cmake: 3.18.1
          cmdline_tools:
            version: '19.0'
            url: https://dl.google.com/android/repository/commandlinetools-linux-13114758_latest.zip
            sha256: 7ec965280a073311c339e571cd5de778b9975026cfcbe79f2b1cdcb1e15317ee
          extra_packages:
            - build-essential
            - curl
            - python3
          image: debian:bookworm-slim
          jdk: openjdk-17-jdk-headless
          ndk: 26.3.11579264
          platform: android-34
          platform_tools:
          tools:
          verify_gradle_wrapper: false

I've matched the environment (home, build dir, etc) to what Github actions use (important with native stuff, as that often embeds build paths etc) in case you wonder. And we use our own gradle wrapper, if there's none in the repo (also to verify the gradle binaries).

Any clue what I might have missed?

[pbsurf]

Try removing the ndk: 26.3.11579264 and make sure ANDROID_NDK is set in the environment. I just have the fallback to 26.3.11579264 for my computer - ANDROID_NDK is already set to something on the Github actions runner.

[pbsurf]

OTOH, if the goal is to generate an identical binary to mine, you could get that NDK version from here: https://github.com/android/ndk/wiki/Unsupported-Downloads I'll update my NDK version to something newer for the next release.

[IzzySoft]

Oops, looks like both notifications were lost… Well, guess we better wait for an official NDK then:

• removing NDK and then setting ANDROID_NDK to … what, if there is no NDK anymore then?
• yes, the goal is to generate an identical binary

Looking forward to the next release then – and to you naming the corresponding NDK version.

[pbsurf]

Actually, I'll probably stick with NDK 26.3.11579264 for now. Looking at the error again, my idea to remove ndk: 26.3.11579264 was wrong. Is the rbtlog build machine ARM or something other than linux x86-64? If so, I have just pushed a commit that should fix the error. Otherwise, if /home/runner/android-sdk/ndk/26.3.11579264/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ does not exist, the issue might be with rbtlog since that should be the correct path for that ndk version on linux x86-64 - what is the first missing directory in that path?

[IzzySoft]

Is the rbtlog build machine ARM or something other than linux x86-64?

All our current builders are amd64 (not sure about the independent builders, though).

what is the first missing directory in that path?

Can't tell "from outside" – all builds run in ephemeral containers, which are abandoned at build end. If no NDK is installed, all from ndk on might be missing. With ndk:26.3.11579264 installed, at least 26.3.11579264 should be there.

OK, so I've added a bunch of ls commands to the build recipe to find out (oh my, half a gigabyte downloads just for that) – and it's the toolchains which are already missing:

+ ls -l /home/runner/android-sdk/ndk/26.3.11579264/toolchains
ls: cannot access '/home/runner/android-sdk/ndk/26.3.11579264/toolchains': No such file or directory

Is there an sdkmanager command to install them?

[pbsurf]

The ndk/26.3.11579264 directory is there, just the toolchain is missing? I don't know of a way to install the toolchain separately - maybe see what sdkmanager --verbose --install 'ndk;26.3.11579264' prints?