F-Droid: Our build and release infrastructure, and upcoming updates

[Posted May 25, 2022 by corbet]

Here's an update from F-Droid regarding upcoming changes to its build and distribution infrastructure.

If you have an app on f-droid.org, you might have noticed that all builds happen on a 5 year old Debian release: stretch. We are in the midst of a big effort to upgrade to the latest bullseye release right now. This is not just a simple apt-get upgrade, we are also taking this opportunity to overhaul the build process so that app builds work with a relatively plain Debian install as the base OS. We have to provide a platform to build thousands of apps, so we cannot just upgrade the base image as often as we like.

to post comments

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 25, 2022 20:28 UTC (Wed) by callegar (guest, #16148) [Link] (14 responses)

I have been happily using F-Droid for a long time now. I still have a question that remained unanswered about it, so if someone could shed some light on the matter, I would be grateful.

Apparently Google prevents apps delivered via F-Droid from using some services. For instance, Fair Email is generally capable of doing OAuth, but not in the F-Droid build. I was expecting Google to favor versions delivered via its store. Yes, the same apps obtained from other sources different from the play store are fully capable. For instance the GitHub binaries of Fair Email can do OAuth.

Indeed, the FairEmail page on F-Droid states "OAuth was not approved by Google for the F-Droid build. For this you'll need to use the Play store version *or the GitHub release*."

What is that Google dislikes so much about F-Droid, but finds OK about binary releases on GitHub?

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 25, 2022 20:32 UTC (Wed) by randomguy3 (subscriber, #71063) [Link] (7 responses)

My assumption for OAuth is that it's related to the client secret (a secret token that identifies the client, allowing servers to reject connections from clients they don't trust even if the user credentials check out) - it's one thing for the app author to hold it and embed it into their builds, but another for it to be used in public build infrastructure like F-Droid's.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 25, 2022 21:17 UTC (Wed) by bartoc (guest, #124262) [Link] (6 responses)

I absolutely despise the whole client secret situation in OAuth, it's often it's just pointless theatre and secures nothing.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 26, 2022 10:49 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (5 responses)

For the user, no. But it does give service providers a lot more control over what (kinds of) clients are allowed to use their services. *They* love it.

As a user, I like the *idea* of being able to give specific apps access to specific facets of my account instead of free-for-all credentials, but it is needlessly difficult to do it for FOSS apps (e.g., registering as a developer and generating my own key). But I don't think it's worth not being able to use better apps for it.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 26, 2022 14:28 UTC (Thu) by brunowolff (guest, #71160) [Link] (4 responses)

Except on really locked down systems this fake security. Since the key is in the app and not something tamper resistent like a TPM, and running on a machine the user controls, the key can be extracted.

Microsoft does some other fake security with their oath stuff. They only let you login via their web (not REST) interface to keep you from using stored credentials. (One might want to do that to retrieve email automatically and not have to manually reauthenticate when the system periodically breaks when you can no longer refresh your token.) Because their login page is needlessly a javascript mess, logging automatically is hard, but it is in theory doable. I haven't been motivated enough to actually do it, but I have been motivated enough to look around to see what tools exist that might help in doing that.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 26, 2022 18:06 UTC (Thu) by dtlin (subscriber, #36537) [Link] (3 responses)

Authorizing to Google services from an Android app is mediated by Google Play Services, which checks that the package signature matches what was registered with Google. So extracting the "secret" from the app gives you nothing of use.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 27, 2022 16:45 UTC (Fri) by floppus (guest, #137245) [Link]

Interesting. Does microG allow bypassing that?

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 29, 2022 4:41 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

Why is the whole secret thing needed then, if we (we == Google Play Services) trust the package signature check? Can't we just authenticate the application via this check?

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 29, 2022 5:58 UTC (Sun) by dtlin (subscriber, #36537) [Link]

You may have multiple configurations - for example, changing which APIs the key is allowed to be used with - in different app versions, with the same app signature.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 30, 2022 9:10 UTC (Mon) by agateau (subscriber, #57569) [Link] (5 responses)

> What is that Google dislikes so much about F-Droid, but finds OK about binary releases on GitHub?

Google Play distributes apk built and signed by developers (for now), so it is highly probable that the apk of the GitHub binary release is the exact same binary as the one served by Google Play.

F-Droid, on the other hand, rebuilds all applications from source, so the apk is not the same.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 30, 2022 11:39 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

> F-Droid, on the other hand, rebuilds all applications from source, so the apk is not the same.

AFAIK, F-Droid prefers Reproducible Builds. This allows them to build the source on their hardware yet reuse the developer's signing key.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 31, 2022 9:50 UTC (Tue) by agateau (subscriber, #57569) [Link] (3 responses)

I don't think F-Droid reuses the developer's signing key. They sign all builds with their own key.

I have one game hosted on F-Droid and I am sure F-Droid does not have my signing key.

This is why when you try to switch from a Google Play version (signed with the developer key) to an F-Droid version (signed with F-Droid key) or the other way around, Android warns you and the new version cannot access data stored by the old version.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted May 31, 2022 13:15 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Ah, they *support* using developer signatures (they don't get your key). Basically, they can take your source and your signature, and if they can reproduce the same binary, apply your signature to the application.

https://f-droid.org/docs/Reproducible_Builds/

F-Droid: Our build and release infrastructure, and upcoming updates

Posted Jun 1, 2022 16:20 UTC (Wed) by agateau (subscriber, #57569) [Link] (1 responses)

Oh, nice! I didn't know about this.

I guess it would not be a good idea to apply it to apps which have already been published using F-Droid key, though, since existing users would not be able to update.

F-Droid: Our build and release infrastructure, and upcoming updates

Posted Jun 1, 2022 16:38 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I think I've seen a few apps "migrate" keys with an explicit opt-in. The F-Droid maintainers may have a path to use here (though save data may be lost, so an export/import option may be warranted).