Hacker News Reader

Comment by lucideer | Hacker News Reader

TIL F-Droid has its own proprietary build system which you have to conform to just to be listed? Is that really the case?

Why? Is it some kind of hand-holding exercise because the F-Droid team don't trust devs to know/understand/check the license of their code?

This seems like an unnecessary extra barrier to distributing FOSS code. And extra maintenance overhead not only for every FOSS app developer but also for the F-Droid team itself (clearly demonstrated by how outdated the Debian build image is).

View on HN

Is it really proprietary or just different from how other Android app stores operate?

AFAIK, they are just doing what every major Linux distro does - they rebuild all software they ship from source on trusted build infra.

Much harder to slip in malware unnoticed, makes sure the source is publicaly available and has the correct license as well as that it can actually be built outside of developers laptop. I guess yoi could also mass rebuild apps that bundle some library that has a CVE found or to make them work on newer Android API levels.

If you just let developpers upload APK blobs you loose all of that.

> Is it really proprietary

"Proprietary" is a vague term, and admittedly its application to anything FOSS is dubious, but in this particular case I was applying it to the process surrounding building & listing on F-Droid, so it would include both software (non-proprietary) and also human processes (seemingly proprietary? maybe?).

My use of the term in this context was merely to emphasise the non-idiomatic nature of it.

> AFAIK, they are just doing what every major Linux distro does - they rebuild all software they ship from source on trusted build infra.

There's reasonable arguments for doing this for a Linux distro where interoperability with the OS & general configuration scaffolding is key. For example, having a specific packaging format is made much easier by having build infra to build that package. F-Droid uses Google's packaging format. The apps run on a Google-managed OS, and interact with Google APIs & config. There's nothig F-Droid is adding here in the runtime context.

> Much harder to slip in malware unnoticed

Highly debatable; particularly given the outdated nature of their build infra.

> makes sure the source is publicly available

It does but you don't need a custom build pipeline to ensure this.

> and has the correct license

You definitely don't need custom build to ascertain this.

> as well as that it can actually be built outside of developers laptop

This is a reasonable argument, but the hurdle still seems high for minimal benefit.

> F-Droid uses Google's packaging format. The apps run on a Google-managed OS, and interact with Google APIs & config.

I think you are wrong here:

1. APK is the Android (AOSP) package format. While Android is primarily developed behind closed doors at Google, the OS itself contains no Google dependencies.

2. F-Droid runs fine on Google-free devices. I think it is safe to say that it exists to provide a complete App Store for Google(-Play) free devices.

Your defining "Google" more narrowly to mean "Google Play and Google services" (understandable as this is common shorthand), whereas I just meant Google the company. AOSP is a Google product and APK is maintained by Google.

Either way it's irrelevant whether any of it is or isn't technically "Google", my only point was that F-Droid do not make AOSP/Android. That's true regardless of your definitions.

> Why? Is it some kind of hand-holding exercise because the F-Droid team don't trust devs to [snip]

The F-Droid team don't and _shouldn't_ trust devs, period.

Trusting them to build and submit their own APKs is how you get the Play Store.

You've [snip]-ed the most important & relevant part of the quote.

The Play Store doesn't ask for nor care for open-source licensing, so your conclusion doesn't make any sense.

I've snipped the specifics you gave because I wanted to assert an even broader statement, including but not limited to what you referred to.

My conclusion was probably not clear. I claim that if F-Droid allowed devs to submit their own APKs, it would open the gates to crapware authors providing a link to an apparently innocent github repo and then submitting APKs full of spyware, ads, crypto miners... I.e. the kind of crap you find in the Play Store.

You don't need to build using their build system to be available via f-droid. You can run your own repository and just provide the APK. If you want to be in their repository they will need to build your app. There also other restrictions to be in that repository like not being allowed the use of Google services etc.

It sounds outrageous until you realize:

1. The F-Droid team has a set of checks that they perform:

  a. Is the app open source?

  b. Does the app do things that the user might not want? ie access non-free services

2. Sometimes, to get around #1, special forks of projects are created so that apps can be included in F-Droid

3. The volume of new applications seem small enough that the F-Droid team can keep up just fine. The only problem I've seen w/ F-Droid resource problems are updates that take days to show up

4. As other have mentioned, you can opt out by running your own repository. Nothing is locking you into the F-Droid primary servers

I appreciate the additional curation F-Droid brings and I love the fact that I can tell other people to use F-Droid unreservedly and know they won't get anything spammy or freedom restricting

1.a & 1.b can be done without a custom build system as long as source is available. One could have strict requirements to the sourcecode submission to enable automation of those checks if that were an issue, without needing any custom build compliance.

> The volume of new applications seem small enough

Isn't that the point. We're talking about barrier to entry here. The harder you make it for devs to submit FOSS apps the less you're going to have.

> As other have mentioned, you can opt out by running your own repository. Nothing is locking you into the F-Droid primary servers

This is a fair point and I have done this for e.g. Guardian Project, but it isn't as straightforward as it could be. If F-Droid made these a bit more discoverable it'd be a great compromise.

I'm the opposite of you. I want the code to be rigid and deterministic.

I want fdroid to be reliably exactly what is on GitHub.

If you want anarchy, you can add your own repositories or download apks.

That all being said, code currently isn't deterministic, so fdroid could improve here.

I'd love to be the same as you, but I've been an F-Droid user for many years, and I still reluctantly but heavily rely on Aurora[0] because of the dearth of good options on F-Droid. I don't mean to shit on the efforts of FOSS maintainers, many of the apps are amazing, but F-Droid is packed full of abandonware, and I can't help but thinking that creating more barriers to entry doesn't help those maintainers.

These strict approaches to vetting software we use are lovely in theory, but in practice the open-source community is criminally under-resourced, and applying further self-taxation on top of that isn't really ideal.

This isn't to say we need to compromise on security: you can have checks in place ensuring source is accessible for listing approval, and if you have infra available you can run static analysis and software-composition analysis on said source. Neither of those automation steps involve significant barriers for maintainers to submit (the only potential barrier is in acquiring approval for very insecure software if checks fail), and both would improve security significantly above and beyond the current custom build requirements.

You can argue the resources required for SA / SCA may be greater than those required for custom build, but if that's the case then you're evidently not doing custom builds for security reasons, so the argument is moot.

[0] https://f-droid.org/en/packages/com.aurora.store/

Reply on news.ycombinator.com