Reproducible Builds

[IzzySoft]

I've checked your app if its build is reproducible (see: Reproducible bulds, special client support and more in our repo), but I wasn't even able to build the app at all, getting the following error:

> Could not resolve all files for configuration ':app:releaseCompileClasspath'.
   > Could not resolve com.nerdoftheherd:android-dropbear:2024.85.
     Required by:
         project :app
      > Could not resolve com.nerdoftheherd:android-dropbear:2024.85.
         > Could not get resource 'https://maven.pkg.github.com/ribbons/android-rsync/com/nerdoftheherd/android-dropbear/2024.85/android-dropbear-2024.85.pom'.
            > Username must not be null!
   > Could not resolve com.nerdoftheherd:android-rsync:3.3.0.
     Required by:
         project :app
      > Could not resolve com.nerdoftheherd:android-rsync:3.3.0.
         > Could not get resource 'https://maven.pkg.github.com/ribbons/android-rsync/com/nerdoftheherd/android-rsync/3.3.0/android-rsync-3.3.0.pom'.
            > Username must not be null!

We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that. Though of course first this general build issue needed to be solved…

Looking forward to your reply!

[ribbons]

This is due to the lovely behaviour of GitHub only allowing access to public package registry packages for authenticated users :facepalm: (see ribbons/android-rsync#42 for some earlier context) - the Dropbear and rsync binaries are published (by me) to GitHub package registry and fetched as dependencies of this project.

As a workaround, you can set the Gradle gpr.user and gpr.key properties or the environment variables PKG_USERNAME and PKG_TOKEN (depending on which is most convenient for rbtlog), these are picked up by build.gradle.kts.

I have the properties set in gradle.properties on my local machine and use the environment variables for the GitHub Actions CI and release process.

[IzzySoft]

That sadly won't work with the rebuilder. Environment variables are not propagated into the container, and I won't put credentials in plain text to the recipe, which is public. Would there be no alternative – like, having them in a git submodule?

[ribbons]

Okay, that's unfortunate. Re: a submodule - sadly not as the other repos set up the necessary toolchain, then build and package the binaries (which is what are needed in this app).

[obfusk]

I understand that publishing to e.g. Maven Central would cause more work for you. But being unable to build the app without a GitHub account is a blocker for Reproducible Builds. And also somewhat in conflict with the FOSS principle that anyone should be able to build their own, without restrictions.

That said, from a quick look at the build scripts it seems the two dependencies aren't that hard to build (though the artefacts may not be reproducible -- e.g. if there is an embedded build ID -- without some changes). The main issue seems to be that the JAR generation code is in the github workflow. If you could factor that out into a separate script that can be used to build and publish not just to github as you do now but also alternatively to a local maven repository, we could use that during our build.

The issue then is how to match the version of those dependencies' repos against the version needed by the app, which is where having them as submodules as Izzy suggested would help.

[ribbons]

After mulling it over (and discovering that GitHub no-longer seem to have any plans to enable anonymous access for their maven package registry, contrary to their earlier statements), I think I'll go down the route of attempting to publish those builds to Maven Central. That would have the benefit of also helping out folks with use cases like ribbons/android-rsync#42.

Will take me a while to get to this though as I'm rather mired in some other projects at the moment.

[IzzySoft]

Thanks! And yeah, no rush, there are no "deadlines". We're looking forward to your ping whenever you found the time to tackle this. We might show up with a friendly heads-up every now and then, though, if you don't mind – not too frequent, or fourse :smiley:

[IzzySoft]

Just a friendly heads-up: any news on this (or an ETA when we can continue with RB), @ribbons?

[ribbons]

Just a friendly heads-up: any news on this (or an ETA when we can continue with RB), @ribbons?

That's a really odd coincidence... I was starting to fumble my way towards figuring out an actions job to publish the dropbear binaries to Maven Central yesterday evening! So yes, finally in progress 🙂.

[IzzySoft]

Great news! More of such coincidences please wherever I send heads-ups :rofl: