Linux Mint Disabling Unverified Flatpaks By Default

[woddy]

Fantastic decision, hopefully other distros follow the same decision and eventually by default no unverified apps are being displayed to users.

If you disagree I ask you this - What is the end goal of Flatpak?

Should the goal not be to eventually have companies like Microsoft, Google, Adobe, along with open source projects like Inkscape, Blender and Krita, all maintaining their own Flatpaks for their apps on Flathub?

The problem with a Flatpak app that is unverified - aka an unofficial third party maintained Flatpak of an application - is that the original developers, who are the only ones who have the power and authority to fix things have absolutely no involvement.

For an app that is currently unverified, if anything is currently broken in the Flatpak UX, the app developers, don't care. They would rightfully say: "I don't care if your Flatpak version of our app is broken - we didn't put out a Flatpak version of our app, we didn't endorse it, we didn't tell you to use it, we supplied our own official version of the app that we recommend, you should be using that, not coming to us with issues about something we have nothing to do with".

The situation as it currently stands, has unverified and verified Flatpaks side by side in the search results for users, who are not going to notice or care about a little tickbox next to some icons and not others, and expect an app called 'Spotify' for example, with the Spotify logo, that connects to Spotify, and looks like the Spotify official app - to be created and maintained by Spotify, not 'John Smith, random internet open source community member' - and even if they understand it's not official, they would still expect it to work.

And when they raise their complaints to the third parties often maintaining those Flatpaks, the answers they get are often not satisfactory. Complaints are often either blown off or ignored, responses to "The sandbox breaks function XYZ that I need in the app" are often met with "Too bad, mah precious security sandbox" type answers.

And even when the third party does care and is willing to do anything they can to help ensure the app works and is reliable, in many cases there's nothing they can do, since fixing the problem would mean getting the developer upstream to make changes to the app to accommodate Flatpak's eccentric requirements.

When a user installs a Flatpak and has a bad experience in an unverified app, due to Flatpak sandboxing breaking the application, and go online to investigate why that is happening, and discover the root cause of the problem is, 'Well it's because the developer has no involvement in the Flatpak, it's basically a hack', they're going to conclude 'Oh, so, Flatpaks suck'.

This is already happening every day.

So in my opinion, long term, what we should want is eventually ALL apps on Flathub to be 'Verified' apps. To be maintained by the app developers themselves, and for those app developers to actually care if their software works well as a Flatpak or not.

And for users, the best thing we could do for them, to ensure people have a good experience with Flatpaks and want to use/adopt them, (to incentivise developers to support Flatpaking) is to ensure users have good experiences by shepherding them towards Verified apps.

And this change doesn't restrict anyone's ability to use non-verified apps either. It's a simple tickbox, tick it and you got access to everything. But at least by having a tickbox, it forces the user to be consciously aware of what they have signed up for, and what they might experience, which will make the user far more sympathetic when something goes wrong.

The only people who won't find that tickbox are the people who probably should be sticking to verified apps anyway, because if they can't find that tickbox, they aren't going to find Flatseal or a random Github issue that tells them which permission they need to change to access files on an external drive, or whatever other random issue they end up having.

This is a good change, and in my opinion, is a change which should have been present with Flathub and Flatpak on all distros from day 1. Pushing unverified third party packagings of apps in sandboxes that they weren't designed for, only hurt Flatpak's reputation.

Is your point about flatpak also valid for deb or rpm? You should know that those you find in the repositories are not distributed and packaged by the application developer, who has probably never explicitly authorized that distribution, especially on Lts distributions that remain in obsolete versions where not even the bugs are fixed. The problem is that many developers don't have the time or desire to do it, which is why, being open source applications, they are packaged by the community or distribution.

[billyswong]

So what's the point of having a mechanism that only verifies the author of a flatpak submission has write access to some random hosting/domain they selected. It proofs nothing in terms of integrity, confidentiality or even authenticity. Not to mention that your flatpak could build its binaries from sources at any kind of hosting/domain that is completely unrelated to that unique identifier. There's nothing linked to it. Nothing at all, except the blue check mark.

So how is my complaint invalid? Please explain.

When people talk about supply chain attack for open source software, the major attack point is source code shown to public is not truly the binary package one get downloaded and installed, but with hidden modification / addition / omission. Ideally, if every software in Flathub is open source, Flathub may enforce a procedure such that it is Flathub who do the software compilation / building / making / packaging, similar to how various Linux distributions maintain their official repositories. Unfortunately, Flathub need to accommodate closed source software too.

For closed source software, they by definition don't show their source code to public. Most, if not all, "own" a website though. So a rational choice for Flathub is to check if the submitted software and the official website claimed by such software are indeed managed by the same organization.

When we say one "own" a website, it doesn't need to be "owning" a 2nd-level domain. "Owning" a 3rd-level domain like those projects hosted in Github, Gitlab etc is also a valid form of "owning" a website. Unless you want to argue Github as the hosting may do malicious impersonation. But then all bets are off. You may as well disqualify the whole Linux Mint distribution solely for its use of Github as their git hosting.

As mentioned before I know at least one FOSS project which has this problem. It's published under GPL3 and it's still now blocked on Mint by default. If the idea was to block free software for your users, well done I guess.

How about you point out the exact project in trouble? We will see what went wrong more clearly. Personally, if I own a hobby project but (1) I don't host it in any big-name open source software hostings and (2) I don't maintain or control any website accessible to the internet either, I won't mind if I can get my hobby project listed in Flathub as "verified app". This hobby project is going to be for my own use plus a few friends only anyway. It is reasonable for strangers to not take my hobby project seriously.

[TheJackiNonster]

How about you point out the exact project in trouble? We will see what went wrong more clearly. Personally, if I own a hobby project but (1) I don't host it in any big-name open source software hostings and (2) I don't maintain or control any website accessible to the internet either, I won't mind if I can get my hobby project listed in Flathub as "verified app". This hobby project is going to be for my own use plus a few friends only anyway. It is reasonable for strangers to not take my hobby project seriously.

The project I have in mind is called "Manuskript". The website for it is hosted by the original maintainer of the project which started it. But since he didn't have the time to contribute or maintain it, that role moved - even multiple times. This is also some behavior which is to be expected for FOSS projects since they usually don't have a proper financial stability, neither do they die when maintainers or original authors stop contributing. Because FOSS is shared entirely with the community.

Sure, for proprietary apps this sort of verification method from Flathub might work. Also I agree that it would be ideal if Flathub would do the compilation for FOSS applications. Currently that's actually what they are doing for most FOSS apps. However compilation isn't 100% of the build process. It's still up to Flathub whether they check and verify the sources (including code and build configuration files) before building. I doubt they have the capability to do that.

So my problem is that we establish a verification process on Flathub now that is intended for proprietary apps while users more likely want FOSS apps, I assume. However FOSS apps may even struggle with that exact verification process. That is my issue. It is shifting the Linux desktop into the direction of proprietary software on the back of FOSS. Maybe this is intended because Flathub predicts that they need proprietary apps in the future to finance Flathub as soon as they implement their payment method. But I think it's the wrong move. Proprietary apps on Flathub should have a place. But FOSS apps should definitely not be second-class citizen.

[anda_skoa]

Sure, for proprietary apps this sort of verification method from Flathub might work.

Not necessarily, as the software development department might not have access to the web site either.

I wonder if Flathub would considered signed commits as an alternative for those rare cases where the domain is not under control off the app uploader.

Adding an app required a commit on the flathub repo, so if this commit is signed and the app's release commit (or tar ball or binary flatpak) is signed with the same key, then this would also verify that the one "uploading" the app is also in control of its repo.

[TheJackiNonster]

Adding an app required a commit on the flathub repo, so if this commit is signed and the app's release commit (or tar ball or binary flatpak) is signed with the same key, then this would also verify that the one "uploading" the app is also in control of its repo.

I would like such an approach much more than what we have now, honestly. That would probably increase the use of GPG as well. People could verify those commits and signatures by themselves as well, rather than only trusting Flathub.

I think one downside is that proprietary apps won't have the possibility to sign commits. But as alternative they could simply sign the published binary. So something like this should work for all in theory.

Maybe they didn't go this way because depending on the complexity of your flatpak manifest, many would use tarballs of releases instead of git history picking specific tags from releases. Also not every project necessarily uses git or properly tagged commits for releases (besides only a few people actually signing commits). Also in the end you would need to verify multiple sources, many times even from repositories you didn't commit last (you will likely have dependencies, right?). So it's unlikely you could register all needed keys on Flathub anyway. You could sign the tarballs from your dependencies though. Better than what we are facing at the moment, I assume.

[billyswong]

The project I have in mind is called "Manuskript". The website for it is hosted by the original maintainer of the project which started it. But since he didn't have the time to contribute or maintain it, that role moved - even multiple times. This is also some behavior which is to be expected for FOSS projects since they usually don't have a proper financial stability, neither do they die when maintainers or original authors stop contributing. Because FOSS is shared entirely with the community.

If you take the recent XZ fiasco in mind, I hope you can see why Flathub is unforgiving in particular to situation similar to your "Manuskript" project. One might even say this kind of "the original creator being out-of-touch but the project lives on the original creator's reputation" may be what Flathub specifically target against. I guess Flathub is pushing project like yours to either (1) nudge the original creator to come back to at least perform the minimal responsibility, or (2) rename the project a bit so that it no longer stands on the reputation of the original domain name or the original author.

If the original creator of a project is still alive and contactable, in theory they can either (1) upload the latest hash file periodically, or (2) share or transfer part of the domain access right to the new maintainer they trust. If neither can be done because the domain is mainly for personal use and the situation of the original creator is so bad that they can no longer access internet regularly, maybe you shall consider a change of the project domain name now, before the personal website collapse on a random day.

[anda_skoa]

I think one downside is that proprietary apps won't have the possibility to sign commits. But as alternative they could simply sign the published binary. So something like this should work for all in theory.

Right, the publisher would sign whatever artifact they upload for a release:

• For something that is built from git it would be the release commit.
• For something released as a tar ball it would be that tar ball.
• For something released as a binary it would be that binary.

besides only a few people actually signing commits

True, but this would only be one of several alternatives.

The core of the idea is to use existing signing options instead of replicating full signature infrastructure that proprietary app stores use.

They could also still keep the "verify my web presence" method as a fallback.

[TheJackiNonster]

If you take the recent XZ fiasco in mind, I hope you can see why Flathub is unforgiving in particular to situation similar to your "Manuskript" project. One might even say this kind of "the original creator being out-of-touch but the project lives on the original creator's reputation" may be what Flathub specifically target against. I guess Flathub is pushing project like yours to either (1) nudge the original creator to come back to at least perform the minimal responsibility, or (2) rename the project a bit so that it no longer stands on the reputation of the original domain name or the original author.

If the original creator of a project is still alive and contactable, in theory they can either (1) upload the latest hash file periodically, or (2) share or transfer part of the domain access right to the new maintainer they trust. If neither can be done because the domain is mainly for personal use and the situation of the original creator is so bad that they can no longer access internet regularly, maybe you shall consider a change of the project domain name now, before the personal website collapse on a random day.

I don't see how any of this would be necessary when the source code is published under GPL. Flathub also started this verification process before the XZ fiasco. So I don't see how they are even related. I flatpak manifest is still fully capable to inject malicious code and tarballs used for building aren't properly verified either.

But let's assume everything gets setup as you said. You have only one maintainer who manages the flatpak, the website and needs to be active developer, I suppose. What happens if such a person dies by accident or can't get into their account for some other reason? I assume, this would effectively block all further updates, despite contributors would easily be capable to fork the project and continue. So this whole idea of centralizing authority ends up in a lot of duplicate "official" flatpaks.

It's not a solution but another problem.