Issues with reproducible builds

[IzzySoft]

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). We're just adding your app, and so I gave it a try: I was able to successfully generate the APK using ./gradlew assembleRelease, but the resulting APKs were not identical – because that APK was not built from a clean tree at the commit the tag points to (but rather from the code of this commit and before you committed it).

We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that. In your case, that would simply be what we call the "first basic rule", as outlined above: always build the APK from a clean tree at the commit behind the tag. I had to apply some tricks (checking out that commit, then performing a soft-reset to the tagged commit) to succeed with a reproducible build, but that would mean manual updates. So if you'd please adhere to the outlined procedures, that would make things much easier :wink:

That said: your app will become available here with the next sync around 6 pm UTC – so be welcome to pick a badge to link there e.g. from your Readme :smiley:

Looking forward to your reply!

[IzzySoft]

PS, while I'm here: could you please also take care for this one?

Easy to be fixed with just a minor addition to your build.gradle:

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. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

(and yes, F-Droid will ask for that as well once they pick up your RFP. Where btw the bot complained about missing Fastlane; I could provide that via a PR with what is set up at IzzyOnDroid if you want.)

Thanks in advance!

[IzzySoft]

Had to tweak it a bit to get today's release RB – spaces in file names are tricky :wink:

app/build/outputs/apk/release/QuickMDCapture 1.2.0-release-unsigned.apk

That – and once more you committed & tagged after having built the APK, so the commit hash embedded in the APK didn't match the tag.

Not sure if you're even reading this, @Fertion, as there wasn't any comment from you here yet…

[Fertion]

Had to tweak it a bit to get today's release RB – spaces in file names are tricky 😉

app/build/outputs/apk/release/QuickMDCapture 1.2.0-release-unsigned.apk

That – and once more you committed & tagged after having built the APK, so the commit hash embedded in the APK didn't match the tag.

Not sure if you're even reading this, @Fertion, as there wasn't any comment from you here yet…

Hello, sorry for the silence. I just haven't worked through these two questions yet, so I didn't know how to respond properly. I expected reproducibility this time, as I built the APK from the same commit that has tag 1.2.0, but apparently I misunderstood something. I plan to look into the issue and meet the requirements a bit later. Once I fix it, I'll definitely update you.

Easy to be fixed with just a minor addition to your build.gradle:

This issue was fixed in this commit https://github.com/Fertion/QuickMDCapture/commit/7045014ba0ff505db1b52879931804d776fb2849

[IzzySoft]

Thanks for your reply, @Fertion! To clarify: your app has the "green shield" up, I could successfully build and reproduce it – but only after applying some "tricks". One is to correct your commit. What you seem to do is to first build the app, and when that succeeds you commit the latest changes. So the APK carries the previous commit (we can automatically correct that here, so that's not a big issue as long as it's "consistent"). Ideally, you'd build the APK you attach at the release from the commit the tag points to – that is, after you made that final commit (see: "first basic rule" in our hints on reproducible builds).

Spaces in file names often cause issues (you introduced one with the latest release); luckily I found a way to work around that as well:

        build:
          - git reset --soft cac30cb805f9ae994b44048e787e2ccccc9aa4b1
          - chmod +x gradlew
          - ./gradlew assembleRelease
          - git clone -b v0.3.0 https://github.com/obfusk/reproducible-apk-tools.git
          - OUT="app/build/outputs/apk/release/QuickMDCapture ${APP_TAG}-release-unsigned.apk"
          - reproducible-apk-tools/inplace-fix.py --internal --page-size 16 fix-newlines "$OUT" 'META-INF/services/*'
          - mv "$OUT" /outputs/unsigned.apk

• git reset --soft corrects the commit hash embedded in the APK
• inplace-fix.py fix-newlines takes care for the different line breaks (you obviously build on Windows, we build on Linux). The trick here was to pass the file name to the script, where the file name contains a space and a variable component (versionName).

So if you keep your workflow as it is now (the name of the output APK changed since the previous release, so we had to adjust manually again), the next release should be RB "out of the box" (the tooling we use takes care for the commit hash update automatically – also if you switch to building "properly" from the correct hash, just not if you one time do and the next time not :wink:) – so we can consider the "issue with reproducible builds" solved.

What still remains is the issue with the signing block blob (see above, including for the fix). And if you could clarify what for the RECORD_AUDIO and SYSTEM_ALERT_WINDOW permissions are needed, we can add those to the app's "green list" so they do not show up as warnings :wink: