> We’re not getting too hung up on the “malicious developer inserts evil code in the binary” case because Flathub already works on the model of verifying the developer and the user makes a decision to trust that app.
Not sure I agree, it's the difference between being able to review the code (not saying everyone) and having absolutely no idea what's packaged.
- I see "stores" such as Flathub or App Store mostly as infrastructure, and infrastructure should be a commodity. Still, whenever you can choose a supplier for a commodity, you should make a conscious decision based on questions such as "are you really 100% renewable 24x7 or are burning coal to handle the peak". Blog posts such as these should be a part of Flathub's official "propaganda engine", so that (potential) users get exposure to the outlined problems.
- You can provide users with certain strong guarantees about what your review/testing/distribution process will or won't allow, which sets a minimum baseline of trustworthiness for each and every single app. This can be extremely powerful; I trust Apple's store much more than I would ever trust Google's, solely based on the values both companies represent; however neither of them could ever hope to be as trustworthy as Debian.
- Providing a paid builder service to proprietary apps could be a strong incentive by itself, and help the bottom line. Apple launched a build service, but infamously does literally nothing at any and every stage to help accommodate FOSS apps in their ecosystem. What if Flathub could get one step ahead, and show everyone: "OK, you have a different business/source access model, we recognize that, and we're willing to accommodate you". I feel that it has the potential to generate a lot of goodwill from both users and developers, and then also influence the industry at large.
I think for a store like flathub to be competitive, it should just remove as much friction form the release process as possible. Most upstream developers will likely have their own infrastructure. So, the added value is dubious. And imagine every other store insisted on this, that would add up to a lot of build hassle for developers.
And of course not all applications are open source to begin with and a lot of those have a lot of other stores to worry about as well. There are probably very few exclusive Flathub only applications out there. A lot of them are also in Ubuntu's snap store. And then there's the Apple store, the windows store, etc.
So, I would recommend to focus on growing the application ecosystem instead of putting up a lot of obstacles and bureaucracy. Make it easy for popular (proprietary and OSS) application developers to target Linux via Flathub. Putting up all sorts of requirements on where and how to build is not helpful for that and likely to make people think twice before bothering with a Flathub release.
> Most upstream developers will likely have their own infrastructure. So, the added value is dubious.
They could make it optional; but the artefacts of those who use it, would be more trustworthy, since flathub can guarantee their BOM. The same way, as you can trust binaries from F-Droid more, than from Google Play.
> The same way, as you can trust binaries from F-Droid more, than from Google Play.
Actually, no. I'm forgetting the exact details - but F-Droid (if I recall correctly) re-signs all packages with its own key, removing the developer's signing key. There's some infrastructure reason for it. Google Play keeps that key.
This is also why GrapheneOS offers sandboxed Google Play and recommends using that over F-Droid.
F-Droid will use your original signatures as long as they can rebuild the binary to be identical (excluding the signature), to verify that everything is open source. They only discard your signatures if they can't confirm that, to avoid issues with hosting proprietary bits.
I run GrapheneOS. It's an amazing project, and I always pay attention to what their developers say.
But you should keep in mind that the GrapheneOS project is very laser-focused on a certain threat model: aggressively malicious software that tries to exploit vulnerabilities to escape its sandboxes. And they fight against that threat very well (there have been a couple of recent high-profile Android CVEs to which GrapheneOS users were immune).
But they are - rightfully - less concerned about the far more common threat of apps including crapload of tracking libraries, battery-burning ads, or dark patterns requesting unnecessary permissions. They provide you with tools to fight them - Storage Scopes and Contact Scopes are amazing! - but ultimately it's up to the user to e.g. choose a serious calculator app like Calculator++ instead of some spyware.
And against that threat, it is an excellent idea to search on F-Droid first instead of the Play Store (where the first non-Google, non-Samsung result is indeed an ad-filled spyware calculator). Then, if you want to secure yourself against the possibility of the F-Droid signing keys being compromised, you may choose to delay/disable automatic updates, or simply to download the Play Store version of the F-Droid-hosted apps.
> Putting up all sorts of requirements on where and how to build is not helpful [...]
Well that's the general trajectory of what I'm thinking about - NOT hurdles, but infrastructure AND incentives for developers, that will help their products grow, OSS or not. What if Flathub helped you publish native Linux builds on Steam?
> Most upstream developers will likely have their own infrastructure.
Bingo. Right now to cover the three major platforms on self-hosted infra, you need to at least 1. buy a Mac, which no longer has an x86-64 CPU, so no dual/triple booting and the VM story isn't exactly here yet, 2. therefore also buy a PC, which you probably want to dual-boot if you're cost-conscious, which means you will probably have either only one native Windows OR Linux builder online at a time, OR make it a VM host which will require more hardware resources and perhaps limit its portability (so you're more likely to buy a more expensive Macbook and make that your portable workstation, rather than a cheaper Mac mini), or 3. buy an extra PC to host the "other" builder.
It's 100% reasonable to go for a hosted CI solution; I'm not saying "let's copy whatever Apple does", but they do offer Xcode Cloud, so that developers can benefit from vertical integration. All platforms benefit from integration, whether it's more horizontal, vertical, or both boils down to strategy, and I think it would be beneficial to explore more angles.
Sure, as long as it's optional. I wasn't necessarily referring to self hosting your own infrastructure but simply to the notion that for most applications out there, building them is kind of a solved problem already and flatpak likely isn't the center of their universe but more like one of several things they need to support.
Offering some build infrastructure is nice but sounds like it would just end up competing with what is out there already. Unless you have a particularly novel/good take on that, you are basically just putting a lot of effort into cloning stuff that you can already get elsewhere for reasonable fee. Making the use of that mandatory vs. use your own and upload the binary is what the article is about. I think not supporting uploads is not really going to be a thing based on the discussion here.
I can't judge the wisdom of adding some optional build infrastructure. Maybe this all just boils down to some people needing an excuse to start doing this because they are interested in building such a thing. I'm not against that of course. Go for it. But it sounds like it would involve quite a bit of cost and infrastructure that isn't necessarily core to what flathub is about.
Flathub, as the most popular repo, ought to be a sensible default for ordinary users. So it shouldn't be purist if that means losing widely-expected apps, but it should have distinctly less shovelware than the Microsoft and Android stores' reputations (and Flathub seems to be taking steps in the right direction here).
I'd like for there to be a well-stocked Flatpak repo with policies like F-Droid's: they insist on rebuilding everything themselves, and they enthusiastically label potential anti-features. But that doesn't have to be Flathub, because using several Flatpak repos at once is easy. (This is really my only objection to Snap.)
Come to think of it, what I'm describing is a traditional Linux distro, so maybe Fedora and PureOS's existing Flatpak repos already fit the bill.
Putting a closed-source application on Flathub is such a pain. Users of our app even request Flatpak support aggressively [0]. Yet uploading pre-built binaries, which is common for most package managers, isn't supported out of the box by Flathub. A direct upload option would simplify so many things...
Flathub does allow the 'build' to download and unpack a pre-built tarball. This is obviously not as convenient as directly uploading it, but some of those enthusiastic users might be happy to get the manifest set up for you, and then updating for new versions should be simple.
(And sorry about the pushy ones. I hope they're few and far between.)
Not sure I agree, it's the difference between being able to review the code (not saying everyone) and having absolutely no idea what's packaged.