Under no circumstances should third-party content be promoted over Fedora content, and since flatpaks are essential for Atomic desktops, that’s exactly what this would do. As I’ve said many times, the Workstation WG should either help with Fedora flatpaks to resolve whatever supposed issues exist, and/or make it easier for users to change the preference order of package repositories in GNOME Software. (KDE DIscover already has such functionality.)
Furthermore, this change proposal is being made for all Atomic desktops without due consultation with their respective SIGs, e.g. KDE SIG for Kinoite etc. I will once again remind the Workstation WG that their purview is limited to the Workstation edition (and Silverblue?), and they neither own the Fedora Flatpaks effort nor can dictate what the rest of Fedora should do.
The improvement to user experience alone is worth every ounce of this change, as has already been demonstrated downstream in projects like Universal Blue which do not ship any Fedora flatpaks.
Well regarding flathub have we considered trustworthiness or security at all?
Sure flathub has some verification in place but unless something has changed, to quote…
"A verified flatpak just means it is packaged by the developer and not a 3rd party. However, believing that all developers understand how to properly package software and that they are properly maintaining any bundled libraries simply because they are the developer would be flawed.
Ultimately, regardless of the package format, it comes down to “do you trust the packager?”. In most cases, you don’t know the packager so it is hard to trust them.
I would argue that it is better to get packages from a distro whenever you can. Most distros have packaging standards and multiple eyes on packages."
Why do the Fedora flatpaks conflict with the Flathub flatpaks at all?
My current understanding is that there is room in how flatpak application-id space is constructed that there could exist vendored application ids such that there is no conflict and both the Fedora and Flathub applications with the same name could be installed side by side. The name and the application id are different strings, there isnt even a requirement that one is a subset of the other.
As a matter of policy, a flatpak remote could claim a specific application-id prefix and other remotes could choose to honor that claim. Flathub policy for example already disallows applications from making use of some prefixes.
Modern applications are tightly coupled to their self-coded application ID, and even if it’s possible to e.g. forcefully rename org.gnome.Foo to org.fedoraproject.Foo, it’s not only a lot of unnecessary work but also may not function 100% correctly.
Flathub has some of the best packaging standards on the planet, and the entire build process is done in plain view in GitHub under peer review, this argument makes no sense.
While I do agree that Flathub has many good policies, they feel a bit “front-loaded” to me. The initial reviews seems thorough enough, but after that, it’s a bit weaker.
For example, it says
Submissions using an end-of-life runtime, extension or baseapp will not be accepted.
Submissions that use high-risk, end-of-life software, such as OpenSSL 1.x, Python 2, or Qt5 WebKit, and request the network or any other invasive permissions may be rejected due to security concerns.
So if the app uses an end of life runtime and insecure vendored dependencies at review time, they will be denied, as they should be. But there is no such policy for existing apps.
So if an app was properly submitted (supported runtime, supported vendored dependencies, etc), it’s now on the store. Time passes. Its runtime may go out of date. The app may be used old dependencies that are no longer supported. However, that app will stay up on the store since there’s no policies regarding removing existing apps that follow bad security practices.
I believe this is the main issue Fedora has with including Flathub by default, that lack of policy to remove such apps.
Apps are delisted if they are not maintained. Pushing runtime updates over functionality is what just got Fedora threatened legally by OBS Studio’s developers for shipping broken software with their trademarks.
Do you have any examples of apps that have been delisted?
I was looking through some of the apps still using end of life runtimes. I saw some apps that haven’t been updated in multiple years and that have home folder access and network access. Example: Install PassVault on Linux | Flathub. And then there are some more maintained apps like Lutris that use EOL runtimes. I know they were holding off updating due to an issue with the Gnome 47 runtime, not sure if that issue is still present in the Gnome 48 runtime.
If an app is using an EOL runtime but has no network access, I think that may be acceptable, if not ideal, as long as its permissions don’t allow it to break out of the sanbox.
Apps are considered maintained and avoid being delisted by building against EOL’d runtimes. But the runtimes that they depend on to build against for updates are not maintained but are still listed.
If you are correct and there is a delisting policy in play for apps that differs significantly for runtimes with regard to maintainence requirements.. feels deeply disturbing to me.
I would have hoped that maintainence policy as it impacts delisting would apply equality to all flatpaks at a particular remote regardless if they are a leaf or a shared runtime.
What about applications that are maintained but use EoL Runtimes that they either refuse to update to a maintained runtime or cannot for whatever reason.
That does not change the fact that this does not work well today.
The proposal here does not include enabling Flathub by default. Just like today, users will get prompted if they want to enable third party repositories and that also enabled Flathub.
Where is this rule written?
This proposal does not enable Flathub by default thus does not promote third-party content over Fedora content.
SIGs have been informed of this proposal and this very thread is also acting as a place to inform people of that change as per the Fedora Change process.
And that’s why this is done as part of the Atomic Desktop SIG and only for Atomic Desktops. We are not dictating what other Editions should do.
AFAIK, you can only install not Flatpaks from multiple sources under a single ID. Renaming IDs is not really an option as this is how apps are identified.
Yes lets talk specifically about Passvault as its probably less dramatic to talk about as an example.
Here is a project that upstream has sunsetted a year ago.
If this had been a Fedora rpm.. what would have happened to it?
I’m assuming that worst case, it could continue to be rebuilt we have just kept mass rebuilding it in rawhide until it stopped building and then someone would have noticed upstream is dead and then the orphan/retire process would have kicked in.
We don’t have an active review for dead upstreams as a process right? So the above is probably worst case. There’s a good chance we’d still have it kicking around in F42 if someone had packaged it as Fedora RPM when it was an active project, caveats being electron apps are hard to package in fedora so this is entirely hypothetical.
Is there real historical example for Fedora packages involving a sunsetted upstream to validate my assumed worst case?
Okay so for flathub what is the anticipated worst case? That this lives on forever, never being forced to be rebuilt as part of some mass rebuild against updated maintained deps? Unless someone notifies the flathub admins and requests it be delisted? Is there any automation here that checks for stale apps like this?
Your answering a different questoin than I asked. I asked about delisting which is different than EOL.
delisting is a point in time after that when unmaintained things stop being made available to download from the rolling distribution.
So for the purpose of this discussion in the Fedora context rawhide is the most equivalent collection of software, because as a collection it rolls, unendingly.
– Play rawhide theme song here. –
For the purposes of this discussion I’m also mapping flathub’s concept of EOL’d flatpaks to Fedora’s concept of orphaned packages.
rpms in rawhide get delisted(aka retired) via the package orphan process as part of the Fedora release cycle. This is a cyclic time-based culling of known unmaintained things that have no package owner willing to do the work to continue to maintain the packages. The result of which is its removal entirely such that users of rawhide as a distribution can no longer download it or build against those packages.
I’m looking to understand flathub’s equivalent process of delisting the unmaintained things from its rolling distribution.
EOL’d runtimes are things that are no longer maintained, they are orphaned in Fedora speak. But Flathub doesn’t seem to have a policy to delist oprhaned runtimes. I’m not even sure what flathub’s policy is to delist unmaintained leaf items like the Passvault app.
Nor does flathub seem to have a process by which other contributors willing and capable of maintaining orphaned runtimes can stand up and take up the burden. In fact that seems to be explicitly unallowed for runtimes. They just continue to exist in an unmaintained state forever it seems. This is not a good thing for a rolling distribution of things.
I have a question about the UX if this change went ahead.
How would me as the user be given the choice between Full Fedora Flatpak repo Vs Flathub Repo. Will this be part of the post-install process that the respective desktop environment?
You mention in a previous posts that this change proposal wouldn’t enable Flathub by default however this quote seems to imply just that. Are you able to elaborate more on this point.
My main worry is that uninformed new users may end up with an empty store just filled with apps that they already have installed.
Replying here but it’s inherently the same issue as in the other thread. You are starting from a position that keeping applications available by default is bad because security. But keeping applications available is actually good because for most of those security does not matter, and having the app, even outdated, is better than not having it.
Of course this does not work for Fedora RPMs because we explicitly rebuild things regularly against newer library to keep things updated as we can not carry older versions.
Again, it’s a mindset change. You can not apply RPM logic to Flatpaks and expect things to make sense. They are fundamentally different format that come with different trade offs.
From what I understood, Atomic Desktops were made for the audience who want to prioritize the user experience (stability and simplicity) at the cost of customization and choices (and maybe even security). At least for me, that’s what I want to use it for, and am willing to make those compromises. That’s why I would support this move away from the Fedora Flatpaks.