-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reproducible Builds #93
Comments
@dstark5 you're still around? |
Yes @IzzySoft sorry for the delayed response |
Hey, are you guys going to fix ( no available mirrors )? I can't download a single book? |
@dstark5 thanks for your response! Do you need additional details from our end (for the differing dex)? @droidjedininja please don't hijack issues not related to your question 😉 It would be much preferred if you could open your own issue. |
Sorry bout that. Wasn't trying to hi-jack your space. I opened my own Issue, thanks. |
Thanks @droidjedininja! Helps to keep things clear 😉 @dstark5 could it be you build on Windows? |
Hey Hi👋, |
Yes @IzzySoft |
Aw… OK, guess then we have no chance to match the paths – and thus cannot achieve reproducible builds. Just to make sure I didn't miss something: cc @obfusk |
You could try setting |
Nope, unfortunately not:
|
Ah. That would require some adjustments to provisioning then. But you could try |
Sorry, that doesn't work either:
Colon is the separator in |
@dstark5 I've just chatted with Fay to see what options are left. We tried some more – but from our end, we can't get it built reproducibly; the only remaining option would be if you could build on Linux. You're welcome to use Fay's rbtlog for that (we could give you our build recipe for that to get you started), which would almost guarantee RB then. As RB is not mandatory at IzzyOnDroid (though highly recommended), we leave the decision to you and of course accept it if you say that's asked too much. Just let us know please what you decide. Thanks a lot for having us supported up to here! |
Hi @IzzySoft 👋 |
As it isn't set up for RB, there are no builds triggered here (the APKs for the repo are taken directly from your releases, signed by you). So what build do you mean? If for RB, until set up that's done manually. And we'd need an APK from you plus the matching tag/commit it was built from. |
I've just tried to build v3.0.9-beta, but failed:
The Flutter version I used here was 3.16.4. OK, switched the recipe to 3.24.4, that seems to work so far (would help if you'd include the Flutter version to use as git submodule, so it doesn't need manual adjustments every next version). Build succeeds, but RB fails the very same way as above (except for the So I guess we have no chance here – as we cannot get the embedded path names fixed? -rw-r--r-- 0.0 unx 56 b- 52 defN 1981-01-01 01:01:02 7e113144 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r-- 0.0 unx 2403 b- 2403 stor 1981-01-01 01:01:02 95cf7338 assets/dexopt/baseline.prof
+ -rw-r--r-- 0.0 unx 2403 b- 2403 stor 1981-01-01 01:01:02 d2004a77 assets/dexopt/baseline.prof
-rw-r--r-- 0.0 unx 240 b- 240 stor 1981-01-01 01:01:02 b1922ab2 assets/dexopt/baseline.profm
- -rw-r--r-- 0.0 unx 7630296 b- 2745438 defN 1981-01-01 01:01:02 e6b9f4c4 classes.dex
- -rw-r--r-- 0.0 unx 8520608 b- 3465630 defN 1981-01-01 01:01:02 8f31006c lib/arm64-v8a/libapp.so
+ -rw-r--r-- 0.0 unx 7630296 b- 2745438 defN 1981-01-01 01:01:02 9090816e classes.dex
+ -rw-r--r-- 0.0 unx 8520608 b- 3459607 defN 1981-01-01 01:01:02 6ef9ecc0 lib/arm64-v8a/libapp.so
-rw-r--r-- 0.0 unx 1022136 b- 304823 defN 1981-01-01 01:01:02 da048360 lib/arm64-v8a/libc++_shared.so
- -rw-r--r-- 0.0 unx 10714448 b- 4990747 defN 1981-01-01 01:01:02 d7d3055d lib/arm64-v8a/libflutter.so
+ -rw-r--r-- 0.0 unx 10714752 b- 4991242 defN 1981-01-01 01:01:02 9f62004e lib/arm64-v8a/libflutter.so
-rw-r--r-- 0.0 unx 53336 b- 21511 defN 1981-01-01 01:01:02 5abf3f4c lib/arm64-v8a/libjniPdfium.so
-rw-r--r-- 0.0 unx 554880 b- 276746 defN 1981-01-01 01:01:02 23f3bea1 lib/arm64-v8a/libmodft2.so
-rw-r--r-- 0.0 unx 5216024 b- 2426621 defN 1981-01-01 01:01:02 c760a7d5 lib/arm64-v8a/libmodpdfium.so
@@ -14,7 +14,7 @@
-rw-r--r-- 0.0 unx 1657 b- 381 defN 1981-01-01 01:01:02 00b04e14 assets/flutter_assets/AssetManifest.bin
-rw-r--r-- 0.0 unx 1509 b- 339 defN 1981-01-01 01:01:02 01a59096 assets/flutter_assets/AssetManifest.json
-rw-r--r-- 0.0 unx 208 b- 111 defN 1981-01-01 01:01:02 f4e36024 assets/flutter_assets/FontManifest.json
- -rw-r--r-- 0.0 unx 108554 b- 103657 defN 1981-01-01 01:01:02 5fcc40b5 assets/flutter_assets/NOTICES.Z
+ -rw-r--r-- 0.0 unx 108195 b- 103351 defN 1981-01-01 01:01:02 249cc23e assets/flutter_assets/NOTICES.Z
-rw-r--r-- 0.0 unx 10813 b- 4463 defN 1981-01-01 01:01:02 dbe919e2 assets/flutter_assets/assets/captcha.svg
-rw-r--r-- 0.0 unx 8201 b- 3260 defN 1981-01-01 01:01:02 0a847596 assets/flutter_assets/assets/delete_confirmation.svg
-rw-r--r-- 0.0 unx 8725 b- 4258 defN 1981-01-01 01:01:02 f271cebe assets/flutter_assets/assets/empty_mylib.svg
@@ -494,14 +494,11 @@
-rw---- 0.0 fat 1171 b- 1171 stor 1981-01-01 01:01:02 0d1f216a res/yq.png
-rw---- 0.0 fat 424 b- 199 defN 1981-01-01 01:01:02 3b16abbc res/z1.xml
-rw---- 0.0 fat 396 b- 228 defN 1981-01-01 01:01:02 cc6ffadf res/z3.xml
- -rw---- 0.0 fat 1996 b- 1452 defN 1981-01-01 01:01:02 f987d267 res/z6
+ -rw---- 0.0 fat 1964 b- 1426 defN 1981-01-01 01:01:02 37103375 res/z6
-rw---- 0.0 fat 1116 b- 523 defN 1981-01-01 01:01:02 ee714821 res/zH.xml |
@IzzySoft what should I need to fix this issues |
As long as we cannot fix the "embedded path" issue, I don't think it makes sense to address the other issues (no need to put unnecessary burden upon you). As we already tried what we can, the only way out of that I currently see is you building the release APKs on Linux instead of Windows. You could e.g. use rbtlog for that, it can be used to "just build the APK and give it to me". We could give you the "recipe file" we used here so you don't have to try-and-err setting that up. And I wouldn't be surprised if the other differences ( Altternatively, a Github workflow building on e.g. Debian or Ubuntu should take care for that as well. In both cases, all that's left is your pulling the APK to sign it, then attach it to releases. If that's asking too much: no bad feelings. We'd simply have to give up then. But RB is not mandatory at IzzyOnDroid – so while being sad, it won't be a show-stopper. RB is just another security feature so people can be confident the APK is really reflecting what it's claimed to be, built from the very source indicated. |
@IzzySoft will do the things you've mentioned. Why 1.0.9 build isn't in izzydroid |
Let me check. Looks like IoD grew so much and most apps are on Github, the updater might be running into API limits – though the logs down't show such here… yupp, manually triggering an update check and it is found. This is the 3rd app now I see this happen to 😢 Wonder why there's nothing in the logs. Well, looks like the pile on my desk is growing… Thanks – and the update will show up with the next sync around 6 pm UTC. PS: the badge on the readme points to |
Ah, btw:
Could you please clarify what those 2 permissions are needed/used for? As for 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. |
Hi @IzzySoft Will add the additions to build.gradle as you've mentioned |
Wait: you need to ask READ permissions for your own files? As I read the explanations of scoped storage, that would only be needed to read media your app doesn't "own" (i.e. created itself). Did I get that wrong? Forgive me then, but not being an Android dev I've never implemented anything along those lines, so I lack first-hand experience.
Thanks! |
Pls take a look and correct me if I'm wrong Also izzyOnDroid doesn't triggered build for new version can you pls take a look at the issue |
That's too unspecific. It doesn't ask about scoped storage, but about read access to storage in general (if I did not miss anything). In other words, author asks what permission they need to read media files from storage – but not if any such permission is required for the files created by the app itself. So let's take a look at the official documentation:
So I remembered that one correctly. What does that documentation say to "Access your own media files"?
According to the app description, you only need access to the files OpenLib downloaded itself, right? Then you won't need the Android 11+ permissions (
UpdateCheckMode: Static That means "monthly checks". Now let's see why, in the MaintainerNotes: - 2024-09-02 UCM Tags=>Static as latest release has VC decreased and thus is daily pulled and deleted right away – https://github.com/dstark5/Openlib/issues/63#issuecomment-2325240850 There was no response at my question yet, hence it's still on "Static" 🤷♂️ And as there must have been 2 checks already meanwhile, and no update showed up at IoD, the issue probably still exists. I see you've updated
OK, that seems to look fine now: repo dir currently holds 2011, 2012 and now 2013, enabling daily checks again. v1.0.10 should become available with the next sync around 7 pm UTC. |
I'd give the RB another try if you could tell me which path you built from (Flutter embeds paths into its libs, so they must match). |
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 by manually specifying the Flutter version (having flutter as a submodule in your git repo would eliminate the manual step here), the differences to the one provided at your latest release were huge. Which is at least partly due to Flutter embedding the build paths into its native libs (could you please let me know the path you are building in?) – but seemingly the APK here was also build from a commit other than the tag points to.
Here's the APK diff:
As pointed out above, the diff in the
*.so
can most likely be eliminated if we use the same build path here that you have. I gladly try another run if you can provide me the mentioned details (build path and commit hash).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: