Since these were proven reproducible above (right?) we technically are 
Indeed, but to avoid support trouble, I’ll wait for decent support in the F-Droid app.
1 Like
sorry i had to comment on this false dichotomy fallacy: having one gmail account does not mean i want to give google root access to all of my computers. it also does not mean that i to give google access to my non-google email accounts.
how can you be sure that the billing library is not grabbing environment around it and posting it to google when it fails to connect to local play services, or when it finds something unexpected with microg? can you provide assurances that it cannot grab the tokens fairemail uses to identify to non-google servers?
maybe that proprietary blob had an EULA that you accepted in which you gave google permission to acquire this telemetry. maybe it shifted the responsibility to you to obtain consent for this from your users, who knows.
the point is that i do not want know, and i do not want to need to know. and this is where F-Droid comes to the rescue with exactly what i need: fully free apps, not partially free apps.
but back to the fallacy…
maybe you are working to take back control of your digital life. it is a tough process, full of friction, exactly as big tech envisioned it. not being all out of the system (eg, having a gmail accont) is no reason not to work in the direction of freeing yourself… one step at a time, one service at a time, one app at a time. thank you for providing a fully free version of FairEmail.
different signing keys surely work to disallow unintended updates, but IMHO this is an abuse of a security feature. if you found yourself wanting (billing) or needing (OAUTH) to publish different versions of the app, i believe these should have different package names… or some other mechanism i do not know about such as release types? did you not already have issues with izzy and playstore stepping over each other? or how did release types fixed this?
for my part, i would love to have a fully free fdroid version of fairemail with oauth, which i think legally requires repro builds. i am totally ok with it having a different package name though.
thanks again.
I can’t change the package name anymore because of the number of users, but you can have OAuth with the GitHub version of the app.
well you could if you wanted. you could publish an f-droid version with a different package name, repeatable builds, and your own signature, which would allow OAUTH on a really free app.
and you could keep updating older f-droid build if you want to support your current users, or ask f-droid to stop publishing… your choice there.
just know that there is a niche that you are not providing for, but you could: a FLOSS client with OAUTH.
(the github version is not an option because it is tainted with proprietary code.)
thanks!
You’ve read News: access removal of "Less Secure Apps" in Google - #66 yet?
Developers can’t directly publish on F-Droid.
Why a reproducible build isn’t an option was discussed before.
OAuth requires signed contracts with email providers, which the F-Droid organization doesn’t have. Some of these contracts are difficult to get, and most of these contracts have an exclusitivity clause.
FairEmail, with OAuth, is available via GitHub. The only thing you’re missing is a third-party build, which is what F-Droid is basically offering.
Fyi the F-Droid build is repro (to itself): FairEmail Reproducibility Status
Yes, I’ve put effort into this in the past, which makes this possible, but as far as I know, this isn’t published on F-Droid, correct?
Yep, becuase we need to change the signing key.
i don’t want to be contrarian. it’s your work and it is great that you are doing it already. and you don’t need to do anything else to deserve my respect.
but…
as i understand it, the whole point of repo builds is that YOUR build with YOUR signature will be published on f-droid, but if and only if f-droid can repro your build themselves.
of course they cannot sign it, because they don’t have your key, but that is irrelevant because they will publish YOUR signed app. the whole point of repro builds, as i understand it, is having a snapshot of the source code that generated the app. that is f-droid’s commitment: if you downloaded a binary from f-droid, they can always provide the source for it. always.
they usual way is that they build and sign the app themselves, so it is trivial.
the repro build case is they build a matching app to yours and check it against yours, and if they match they publish YOUR build with THEIR copy of the source code. this way they are publishing YOUR build but with total assurance that the source in their possession corresponds to your published build.
AFAICT, this solves the OAUTH legal issue of f-doid not signing contracts (because you did and it is your build), and f-droid’s policy issue of having proof of their source generating the app they publish (your build).
this policy is very common in linux distros. but f-droid went the extra mile and provided a way to publish externally signed builds with source assurance. i think they couldn’t have done better: source assurance is their raison d’être.
so i believe (i could be wrong) that you CAN publish an OAUTH build in f-droid with repro builds and source assurance. (it requires your signature, and ideally new package name that does not conflict with playstore. or else a new signature from you but this is abusing signatures for app variants i think.)
you don’t need to do any of this. but you can. and if you did, i’d migrate to it.
again, thanks for all your efforts.
I can, and it was even prepared, but there are good reason to not do this, see earlier in this discussion.
Also, you can already migrate to the GitHub version and have what you want.
no, the github version is contaminated with proprietary blobs.
also, i need to trust you that the published source corresponds to the offered binary, instead of trusting f-droid.
(note that i do trust you, but i protest that trusting you vs trusting f-droid is the same thing.)
the point here was about a niche not catered to.
anyway, thanks for your hard work.
If you mean by proprietary blobs Google Play Billing, this was removed from the GitHub release a while back.
Play Services Basement is the only thing remaining and IMHO that makes things safer and not unsafer, especially for people with older devices. The reason is that the (SSL) security provider can be updated, which is disabled by default for non Play Store builds.
The world just isn’t as simple that something is off or on …