[Bug]: reproducible builds fail due to build-timestamp

[IzzySoft]

Contact Details

No response

What happened?

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Yours was reproducible until today, but now fails. Looking at the DEX diff:

-checksum            : 7c89a9ef
-signature           : cf3c...4f06
+checksum            : 9e8aac60
+signature           : 7cf6...e8a0
 file_size           : 8231956
 header_size         : 112
 link_size           : 0
@@ -987267,7 +987267,7 @@
       name          : 'TIMESTAMP'
       type          : 'I'
       access        : 0x0019 (PUBLIC STATIC FINAL)
-      value         : 1730201604
+      value         : 1730396811
     #5              : (in Lcom/geeksville/mesh/BuildConfig;)
       name          : 'VERSION_CODE'
       type          : 'I'
@@ -1592119,7 +1592119,7 @@
 |: move-result-object v0
 |: invoke-virtual {v3}, Lcom/geeksville/mesh/MeshProtos$MeshPacket;.getRxTime:()I
 |: move-result v3
-|: const v1, #float 7.59268e+23 // #6720c804
+|: const v1, #float 7.73334e+23 // #6723c28b
 |: if-ge v3, v1, 0018 // +0009

suggests a kind of timestamp being included – more precisely, a build timestamp, as the "new" value (from our build) matches the time we built it. And right, here's the culprit:

buildConfigField "int", "TIMESTAMP", System.currentTimeSeconds().toString()

That makes RB impossible, as we'll never build synchronously at the exact same second. Is such a timestamp really needed? Could you remove it again (it wasn't there on the previous version) – or replace it by something else that is deterministic?

We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that.

Looking forward to your reply!

App Version

2.5.6

Phone

n/a

Device

n/a

Firmware

n/a

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[andrekir]

Hello Izzy! Thanks for the heads-up! I'll have this fixed soon and report back.

[IzzySoft]

Thanks Andre! You might wonder that the current release meanwhile shows the "green badge" for a successful RB; I decided to "patch" your build.gradle, replacing that call (System.currentTimeSeconds().toString()) by the timestamp your APK included ("1730201604"). But that comes at a cost: the next release won't be running through RB automatically (cannot, as the timestamp only matches the current one). But with the next release coming without embedded build timestamp would mean we can remove that patch then, and subsequent releases should pass automatically then again.

apk_url: https://github.com/meshtastic/Meshtastic-Android/releases/download/2.5.6/fdroidRelease-2.5.6.apk
build:
  - sed -r '/signingConfigs.release/d' -i app/build.gradle
  - sed -r 's/System.currentTimeSeconds\(\).toString\(\)/"1730201604"/' -i app/build.gradle
  - chmod +x gradlew
  - ./gradlew assembleFdroidRelease

(and yes, we have to remove the signing call as we need an unsigned APK – and don't have your credentials anyway)

[andrekir]

Thank you for that!

I removed the build timestamp in 605ef12. I’ll keep this open until we push a new release.

[IzzySoft]

Wonderful, thanks a lot! I have a note in the recipe here:

notes:
  - 'FIXME: 2.5.6 introduced embedded build timestamp, see https://github.com/meshtastic/Meshtastic-Android/issues/1372 (should be removed with next release)'

The FIXME: in my builder prevents auto-update, as it shall indicate the updated recipe needs fixing (in your case here no longer true as you removed the timestamp, and thus the sed in above quoted recipe simply does nothing – but it should still be removed to keep the recipe clean). Will (hopefully not forget to) report back once it was processed, and close the issue myself then. Should you not have heard back from me within ~48h of your release that either means it wasn't fetched for some reason (unlikely) – or I forgot to report back 🙈