Reproducible Builds #6
Comments
|
Thanks for noticing that that happened, the file wasn't supposed to be there as it's a database I used for testing the app I updated the latest v2 release with a clean build from the same commit It should be good now |
|
Congrats 🥳 That did it! Now there's just one thing left I see: And that's easily fixed at your end, by a little modification to your 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. Thanks a lot! One more thing: while it helped for a quick fix now, please never replace an already distributed file at a release. Better make a new release (can be a "maintenance release"). Those already having updated to the latest release won't get this APK – and now that your app has RB enabled, it would void RB and no longer match the "proof". Starting with the next sync around 6 pm UTC, your app's latest version will carry the "green shield" – and future versions hopefully will hold it up 😃 Preview from staging:
And here comes your "welcome message": https://floss.social/@IzzyOnDroid/112899790609030217 Next (!) release then even without that blob? 😺 |
|
Thank you ❤️ I made a new release without the blob |
|
Then let's see if the updater works, shall we? Looks good! And no mention of that blob 🥳 Want a PR with a Fastlane starter kit? Fastlane would allow you to maintain how your app is presented (description, graphics etc). I could send you what is currently set up with IzzyOnDroid – and you can then use e.g. the IzzyOnDroid Fastlane Documentation to guide you with building on it. Takes me no more than 5 minutes to have the PR open – should you accept. As you see, your adjustments to it would then be checked whenever an update is pulled, and would be pulled along. If you wonder about FUNDING.yml: that is if you want to propagate that and how one can support you with donations. |
|
Yeah, that would be very helpful Thanks again for reaching out! |
|
I will close this as everything seems to have been resolved |
|
RB check for the new release is running already 🤞 Oh, and be welcome to pick a badge to link to Arru's presence at IzzyOnDroid if you wish – multiple variants to choose from, including "shields" from shields.io. I'll prepare the PR soon, just need a little break now. But expect it shortly! Oh, and in case I didn't yet say so: welcome aboard IzzyOnDroid with Arru! 🤩 |
|
And there you go: PR is open! RB for the new release succeeded btw, so with the next sync Arru will show up publicly with 2 RB releases 😃 Oh, and your shield will of course reflect that then, thanks for adding it! |
|
Happy to be part of the Izzy Repo 😄 we need more floss apps on android fr |
Working on it to make more of them available – and the available ones more floss – and all of them more visible plus the system as safe as we can, as you've noticed 😉 Thanks for your help! |
|
@KSSidll v2.4.8 failed RB again. Did you really build from a clean tree at the commit the tag points to? APK diff: -------------------------------
--- /dev/fd/63 2024-08-13 20:05:34.755419539 +0200
+++ /dev/fd/62 2024-08-13 20:05:34.755419539 +0200
@@ -3,11 +3,11 @@
META-INF/version-control-info.textproto
32-bit CRC value (hex): f6fecc61
assets/dexopt/baseline.prof
- 32-bit CRC value (hex): fb927fe9
+ 32-bit CRC value (hex): ded44b15
assets/dexopt/baseline.profm
32-bit CRC value (hex): 75395d5a
classes.dex
- 32-bit CRC value (hex): e9fb32eb
+ 32-bit CRC value (hex): 69228c44
lib/arm64-v8a/libdatastore_shared_counter.so
32-bit CRC value (hex): 4f56ac38
lib/armeabi-v7a/libdatastore_shared_counter.so
@@ -836,9 +836,3 @@
32-bit CRC value (hex): 87d58c52
resources.arsc
32-bit CRC value (hex): 5010ded9I'll reset today's run in the hope you can tell me the commit to use (do not replace the APK please as that's already distributed now), and a subsequent run succeeds then. |
|
huh |
|
i built the apk again from the d60393e commit and it has the same SHA256 🤔 |
|
this is quite interesting i did a clean clone and then built with that, same CRC as what you got somehow deleting gradle build files and building anew created a completely different CRC (classes.dex got 77C71FAF) i think the best way would be for me to containerize the build process instead of building from android studio level |
|
Yes, unfortunately (for Reproducible Builds) Android Studio tends to do "incremental builds", resulting in these kinds of odd differences -- usually in DEX files -- that shouldn't happen. Which is why we recommend cleaning the project and cache before building the release APK, though that isn't always sufficient. And even CLI builds will re-use build artefacts and gradle cache. Containerising your build -- like our completely clean builds in a fresh container -- should indeed help. We do find that CLI builds with |
|
FYI: I'm planning on making it easy to use our |
|
Using the same tool (and recipes) would certainly make it easier for everyone yeah |
|
rbtlog does support Docker as well, if you prefer that over Podman (we mostly use Podman there). |
|
i thought the tool supports RB verification and logging for now, with local apk build coming later, didn't notice that you can save the built apk locally until just now i will experiment with that later |
|
That's what Fay just plans to implement. Once the new feature is ready, you can e.g. call the build script telling it "just build from that commit and give me the APK". I't not yet there; Fay was reaching out for feedback before starting implementation, to know what other "steak holders" (intentional misspelling) think about it. After all, this part is for you who might want to use it to "simply build", so it should cover your needs 😉 |
|
v2.4.8 is marked failed here now as we cannot heal it anymore. Let's see we get this solved for the next release. |
|
next release will be built in a container so it should be RB unless something else goes wrong i will leave this open until there is an actual confirmation of RB (hopefully next release) |
|
Be welcome to give me a ping if I shall test before you release. |
FWIW, this is implemented now :) |
|
From what i see RB passed without issues |
|
Yupp, went through without any issue today, thanks! |
I've checked your app if its build is reproducible (see: Reproducible bulds, special client support and more in our repo), but while I was able to successfully generate the APK using
./gradlew assembleRelease, but there were differences between the APK generated here and the one you provide. Most noticable, your APK seems to contain an additional database:Could it be you've built from a "dirty tree" and that
assets/database/baka-arru.dbshould not even be there?The other differences are easy to fix on our end (you probably build on Windows, as those files have DOS line endings – while we build on Linux and thus the files here have Linux file endings).
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!
The text was updated successfully, but these errors were encountered: