The problem with reproducible builds is that it will immediately result in trouble for all people having installed the app via F-Droid because the F-Droid app doesn’t support multiple release types of the same app. This is something I cannot solve, and which makes reproducible builds a no-go.
Note that I spent quite some time making a reproducible build possible. So, it isn’t that I don’t want a reproducible build.
As F-Droid works now, reproducible builds are an option only for new apps in the F-Droid, with no prior history.
So, if you want to argue, talk to the maintainers of F-Droid.
It is Firefox-specific and using a specific OTP app, so, this is more for a blog than for a FAQ. Moreover, the FAQ already references this help article:
This approach allows publishing both APKs signed by the (upstream) developer and APKs signed by F-Droid. This enables us to ship updates for users who installed apps from other sources than F-Droid (e.g. Play Store), while also shipping updates for apps which were built and signed by F-Droid.
Are these two quotes about the impossibility of the user to switch from F-Droid’s signature to yours without an uninstall/reinstall?
If so, yes that’s one way, users would need to export config (that’s a paid feature in FairEmail iirc?) then reimport on reinstall. There’s also the issue of informing the users, say having F-Droid Client announce such a switch. All known issues.
Now, besides that… F-Droid supports having your repro APK along side F-Droid’s one already, eg NewPipe or Bitcoin Wallet have such a setup (as Lukas posted above while I write this) So new users will get yours, while old ones get updates from F-Droid signed APKs as expected.
Please see earlier in the discussion: people cannot see in the F-Droid app what they are installing. This needs to be solved, else it will cause a lot of trouble, and the burden of this will be on my shoulders, which are already carrying enough.
Yes, UI is not yet ready to expose what is repro or what is not.
F-Droid Client prioritises your APKs.
F-Droid Website lists F-Droid’s APKs first
etc.
Again, known issues, future work is planned to tackle these.
Not sure I follow, whether the APK is signed by F-Droid or you, makes no difference as the contents are identical. Having a user tell you “I have fairemail from f-droid” would just mean “fdroid flavor” to you, no?
New users will only be able to install the reproducible build. They can’t choose and there is no such option to go with an F-Droid signed build. Meanwhile, old users will still receive the updates that are signed by F-Droid.
Version 0.25.2 (994) suggested Added on 2023-08-10
This version requires Android 5.0 or newer.
It is built and signed by F-Droid, and guaranteed to correspond to this source tarbal
scroll down…
Version 0.25.2 (994) - Added on 2023-08-10
This version requires Android 5.0 or newer.
It is built and signed by the original developer, and guaranteed to correspond to this source tarball.
No, look at version Numbers… 5.3.2 (158) and 5.3.2 (157), they are different, each (versionCode) is a different architecture. If you toggle Expert mode ON it will make it clear
look at my website example above Version 0.25.2 (994) is the same in both from F-Droid and from NewPipe devs.
Anyway, if the version signed by the developer is the suggested one, then why would anyone go with the one that isn’t suggested? If you press the installation button it automatically installs the suggested version too.
It won’t protect from updating the GitHub or Play Store version by the F-Droid reproduciable build.
Since the benefit is limited and the confusion will be significant, there are more disadvantages than advantages. The logical choice is, despite the effort put into this, not to provide a reproducible build.
Also, the question “which problem will be solved” remains.
If you want to use OAuth, you can install the GitHub version.
If you want to auto-update the GitHub version, you can use the IzzyOnDroid F-Droid repo.
Here’s one problem that it solves for F-Droid and its users: upstream developers complaining that they only offer support for their own builds from github/play/etc
With a reproducible build, all the bugs are upstream bugs
The Play Billing library isn’t open source indeed, but it won’t do anything if there are no Play Services on the device. It is there to recognize Play Store purchases (obviously) and therefore it can’t be removed.
That said, if you are a purist and don’t want to use Google stuff, you (anybody) shouldn’t use Gmail accounts either.
)
try to look at Bitcoin Wallet of Newpipe (if you don’t have them installed!) and expand Versions in Client
