Reproducible Builds - Githubissues

IzzySoft commented 2 months ago

At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more in our repo). We'd try to enable them for your app, but even before trying we see they would fail:

versionName/versionCode are calculated based on build time – so building our APK on a day other than the one you've built yours would result in a different APK.
tag names like release-next are "moving targets": once you've moved to the next release, the old pointers become invalid and whoever tries to confirm the build recipe then would fail.

We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that – and we gladly assist you with further steps once the two above are solved.

Looking forward to your reply!

cc @obfusk

IzzySoft commented 1 month ago

@mark99i any word?

IzzySoft commented 1 month ago

PS: the team just decided that "moving targets" shall not be used at all, and corresponding recipes should be removed from our builders. That means I'd have to remove AppSearcher from the builder here, so it would no longer show its "green shield" of confirmed RB – which would be a pity. I'll still have to do that if there's not even a response from you, @mark99i – so could you please name the tag properly? Thanks in advance!

mark99i commented 1 month ago

PS: the team just decided that "moving targets" shall not be used at all, and corresponding recipes should be removed from our builders. That means I'd have to remove AppSearcher from the builder here, so it would no longer show its "green shield" of confirmed RB – which would be a pity. I'll still have to do that if there's not even a response from you, @mark99i – so could you please name the tag properly? Thanks in advance!

I apologize for the late answer. I followed your link and didn't understand why and to whom it necessary at all :) I also didn't understand what I needed to do.

versionName/versionCode is generated dynamically by the build script now (based on the current date),

do you want versionName/versionCode to be set manually at the time of assembly? it is possible, but it is inconvenient for me personally. I will be glad to PR if there is another, better way without changing when it is not necessary.

regarding tags: I'm thinking of publishing all the next releases under the same tag `releases-next'. I do not know how well I will succeed, if I fail, then maybe I should not link tags to releases at all?

mark99i commented 1 month ago

@mark99i any word?

in general, I once tried using the f-droid store and found it as inconvenient as possible:

you can't take it and install it - there will be too few applications
you need to manually search for repositories and configure each time on a new phone
the repositories themselves are maintained by various volunteers: this is not bad in terms of decentralization and other things, but it is not convenient from the user's point of view
the quality of the repositories leaves much to be desired

considering all this, even if I don't like gplay, it's easier for me to "google" the application I need and download it from apkpure or a similar site not to mention if I need some kind of modification or rare software

IzzySoft commented 1 month ago

I was talking about the tag name here:

I'm thinking of publishing all the next releases under the same tag `releases-next'.

Which is a very bad idea. You know what tags are for? To identify releases. If you reuse the same tag, previous releases can no longer be identified. Reproducible Builds are no longer reproducible, so you loose a security feature there. Automated updates (like those on the IzzyOnDroid repo) will stop working, as they go by tag names: none of the future releases will be pulled as they are considered to be "already here".

For what you most likely want to achieve, there's the "latest" link at Github – always pointing to what you defined as latest release.

I do not use versionCode and I doubt that I need it.

You do know what the purpose of versionCode is – and that without increasing it on new releases, there won't be any update notifications? Android would consider those "new releases" as "already here"/"already installed". Basically, packageName/appId + versionCode form a unique key there.

As for "what good are F-Droid repositories", that might be a quite subjective question – and many will disagree with your stance (to which you of course have all rights: that's a personal decision). Same for "the quality of repositories" – yes, there are different ones with different standards. Same as there are for Linux distributions, by the way :wink: I (and many others) e.g. use it for years as their sole source of apps. I cannot confirm your statement there. All the repositories I need come pre-configured with my client (I use Neo Store, not the "official one" which mostly focuses on F-Droid.org itself).

TL;DR: I cannot (and do not want to) "force" you onto a specific path. But if you really proceed the way you just described, I will have to remove your app – not only from the verification builder, but also from the IzzyOnDroid repo, as timely updates would no longer be possible and manual checks for updates are out of the equation (with more than 1.200 apps in the repo, they are unfeasible).

No bad feelings there. Just let me know which path you choose, so we can adjust on our end.

mark99i / AppSearcher

Reproducible Builds #4