I do not think this is a good idea. This essentially guts the default content set for Fedora atomic desktops, and sets the stage to force FESCo to permit Flathub to be enabled by default in Fedora deliverables. It also circumvents the existing ruling that first-party content must be promoted over third-party content by disabling availability of first-party content.

-1

The proposal does not make me happy. In a way it is a failure of our packaging and delivery process. People prefer the flathub flatpaks for complicated reasons. I even feel that some of those reasons are bogus… But it doesn't really matter. If we are not able to win people over, trying to force them to use the less-preferred option just makes people angry and doesn't work in the long run. At the technical level, Software already shows the source of the flatpak, see attached screenshot, and I think the menu is readable enough. But again, this doesn't really matter. If people are confused as to what they install, this means that the interface is not clear enough. We could have improved the interface, and over the years many proposals have been made. For example, to make priorities configurable, or to expose the origin more verbosely. (Maybe we should make a pop-up bubble the first time the user has to make this choice, and link to a good explanation, and allow the user to disable the popup for the future. Also, the question of showing the reviews for the top-level name, not for the installation method is problematic if the installation methods are not equivalent.) But despite those discussions, those changes haven't happened, and nothing indicates that such changes are coming.

The proposal effectively follows vox populi. It's not a great solution, but as far as users are concerned, it's better than status quo. Thus, +1.

As a newcomer to Linux I wouldn't even understand what are the differences between the appsources, so all this would make even less sense.
I want to have (obviously, per default) the one that gives me more chance of getting official support.
Having in mind that the user already chooses to have 3rd party repos enabled, just add "per default" in the question. What would be the point of enabling them if it was not for use.
App developers can then opt where/how to distribute their apps.

if this comes to just improving the UI just add:
Fedora Linux (more secure and controled) on registry.fedoraproject.org's title
Flathub (original from the developer) for dl.flathub.org part.

Flathub (original from the developer)

Note that this isn't necessarily true either. Flathub has large chunk of third-party Flatpaks too. Being on Flathub does not guarantee the developer is maintaining the Flatpak.

Flathub (original from the developer)

Note that this isn't necessarily true either. Flathub has large chunk of third-party Flatpaks too. Being on Flathub does not guarantee the developer is maintaining the Flatpak.

Thxs...didn't know that...
Then this discussion is kind of pointless also... except if instead of having the hardcoded string we would do

Fedora Linux (Provided by Fedora) hardcoded on registry.fedoraproject.org's title
Flathub (Provided by ) for dl.flathub.org part.

This would mean if it was submitted by "unverified" sources, == "Unverified Source" raising awareness that it is not from the owner.

This would be giving the user all the tools to make an informed choice.

(...trying to keep this comment limited to meta-discussion, since I know this is not the discussion thread...)

I'm about to publish a long essay on this topic, which I expect FESCo will find interesting when voting on this. Unfortunately, I'm only about 95% finished with writing it. I see this issue is tagged for meeting, and today is meeting day. My suggestion is to wait one more week before voting. In case you decide to vote today, I've left a relevant comment in this Workstation Working Group ticket.

Meeting day is Tuesday, so tomorrow. If you have a chance to finish this essay today, please post it here. You've got roughly 23 hours before the meeting starts, which will hopefully give us time to consider it.

As the de facto maintainer of Fedora Flatpaks, I oppose this proposal, and my essay has been up for a while: https://yselkowitz.github.io/blog/2025/02/25/the-case-for-fedora-flatpaks.html

Meeting day is Tuesday, so tomorrow. If you have a chance to finish this essay today, please post it here. You've got roughly 23 hours before the meeting starts, which will hopefully give us time to consider it.

Oops, sometimes my brain gets off by one day. Here it is. I'm afraid it's ridiculously long, and there's not much time to review it before voting, so delaying another week might be sensible regardless. This would also allow more time to review community feedback.

In addition to this change proposal's discussion thread and the Workstation WG ticket, there is also relevant discussion in this Discourse discussion thread.

This will be discussed in the meeting today.

@yselkowitz and @catanzaro, thank you for the thoughtful writeups.

I'm pretty sure that this wasn't Michael's intention, but his text makes me very worried about the future where flathub flatpaks are commonly used. It apparently hard to get any concrete statistics, which is already a problem in itself, but even partial results indicate the situation is bad. Flathub apps are using EOL runtimes (29%). Nobody knows how many apps are using outdated bundled dependencies, but considering that it's more work to update random deps than the runtimes which generally keep stable APIs, I'd expect that this is much more. This is compounded by the fact that sandboxing is commonly only partial. On top of that we also have apps that are not built from source (6%). Together this means that the majority of apps on flathub do not satisfy the commonly-expected standard safety practices; and any exploits, intentional or not, could potentially have significant impact.

The situation with sandboxing will be hard to improve. If we haven't managed to build functional sandboxing abstractions in the 10 years when flatpaks were in an early technological stage, then it's unlikely that this will happen now, when the current approach has been normalized. In fact, the huge growth in popularity described in Michael's post makes this even less likely.

It's possible that flathub practices and flatpak sandboxing will improve over time. But right now it's too early to say with any certainty whether this will happen. And without those improvements, exposing users to flathub flatpaks is a huge step backwards in software delivery practices. And the more popular flathub becomes, the longer the tail of outdated and insecure packages.

Michael's post suggests a bunch of improvements, but those are very big items and would most likely require years of work. Maybe they are possible, but do we have confirmation from flathub maintainers that this is what they want?

The advantages that Yaakov lists for Fedora flatpaks are quite significant. Michael writes that "maintaining Flatpaks is a tremendous effort", but that is incongruent with the statements that Yaakov, just a single person, is doing majority of the work on Fedora flatpaks. As long as Fedora continues to produce rpms, if the pipeline from rpms to flatpaks is functional, we should get flatpaks almost for free. In fact, flathub could help, because various assets and settings could be copied from there, making it easier to do the builds in Fedora.

An application that depends on an EOL runtime for too long should eventually be delisted. Perhaps 6 months or 1 year would be good deadlines.

I think this is backwards. Normally, in Fedora packaging, we require that anything that goes into a release is expected to be supported until the EOL of that release. For big stuff like "runtimes" we would never allow applications to be built against a version that is already EOL or goes EOL in a few months. Thus, for flathub, I would expect that apps would start being delisted (not shown for new installations) when built against a runtime that has less than a year of supported lifetime. And users should be warned if they continue to use an app using EOL runtime.

In summary, I still think the current proposal still makes sense, because apparently that is what the maintainers and users of the Atomic subset of the distro prefer. I don't think we should try to override that. But it doesn't seem to be a good long-term solution.

Actually you more or less understood what I intended. Flathub is not yet good enough for Fedora.

I'm less pessimistic than you regarding fixing the build from source and EOL runtimes and even the bundled dependencies problems. They are big problems currently because nobody is working on fixing them. With a team effort, maybe it can be solved sooner rather than later. (Or maybe Flathub community will disagree with me and not fix them, and we will get stuck.)

Sandboxing will indeed take longer, but remember that inadequate sandboxing on Flathub is not a disadvantage relative to Fedora.

GNOME runtimes are supported for only 13 months, and KDE runtimes for somewhat less. So cutting off applications when the runtime has only a year of support left does not work. :)

We decided to punt until next week to let people catch up with the discussion.

The situation with sandboxing will be hard to improve. If we haven't managed to build functional sandboxing abstractions in the 10 years when flatpaks were in an early technological stage, then it's unlikely that this will happen now, when the current approach has been normalized. In fact, the huge growth in popularity described in Michael's post makes this even less likely.

I see it the reverse way. Most of the applications still requiring sandbox holes are old ones that probably won't be redesigned to adopt to portals because that would be a lot of work. However, new applications are (hopefully) being developed with Flatpak in mind (as this is getting more popular and the model is also shared with Snaps) and will make heavier use of the portals instead, not requiring too many holes.

Sandboxing will indeed take longer, but remember that inadequate sandboxing on Flathub is not a disadvantage relative to Fedora.

All else being equal, I agree with @catanzaro here. But things are not equal - inadequate sandboxing on Flathub coupled with all the quality issues on Flathub at the moment, seems to me makes unsandboxed Flathub RPMs less trustworthy than unsandboxed Fedora RPMs.

If I understand correctly, the problem behind this request is that Fedora provided flatpaks are of varying quality. Some are ok, other are substandard.

The request is, if I understand it correctly, to allow the Fedora Atomic Desktop SIG to maintain an exclusion list so that they can easily add flatpaks deemed of low quality so that those would be hidden from clients use. Eventually if the flatpaks in the list raises to good quality, the Fedora Atomic Desktop SIG will remove it from the list and leave it available to the clients again.

The problems I see with the previous proposal (obviously if I misinterpreted the proposal those points might not apply:

1. If I remember correctly there is no official definition (ie: FAS group) of the Fedora Atomic Desktop SIG, is this correct? If so, who will be the people making those decisions

2. Adding and removing "frequently" flatpaks from the list would create massive issues, since the users will have different flatpak installed (some will have the Fedora one other will have the Flathub or other sources ones) based on the instant they cliecked "install", which seems a huge no-go to me, since it would make way more complex for the user to understand their exact situation.

3. I think that if there are Flatpaks that are low quality, this means that the QA process for flatpaks is not appropriate (or does not exists at all), so the first step would be to create this process. If, then, some users notice some quality issues with certain flatpaks, they should open a bugzilla bug against them. If the maintainer does not reply and fix the issue, it is possible to use the non-responsive maintainer process to eventually take care of flatpaks that are not up-to-quality and the maintainer is not managing them.

Overall, I think adding this exception for how flatpaks are handled does not help Fedora nor the users since it, on one hand, complicates Fedora management of flatpaks, and on the other hand, makes it even harder for the user to understand what flatpak source was used for the various flatpaks they have on their system and why.

The request is, if I understand it correctly, to allow the Fedora Atomic Desktop SIG to maintain an exclusion list so that they can easily add flatpaks deemed of low quality so that those would be hidden from clients use. Eventually if the flatpaks in the list raises to good quality, the Fedora Atomic Desktop SIG will remove it from the list and leave it available to the clients again.

Yes, but no ;) There would indeed be an exclusion list, but the idea is for the exclusion list to be fixed to include everything not in the base image. In other words, the included stuff would be the stuff that is needed to have a functional live image. Other apps would become available once the users allows 3rd-party repos and then the external apps would be used in preference.

I think that if there are Flatpaks that are low quality

This is complicated. Some are of "low quality" because Fedora doesn't include codecs. Some were outdated because Fedora rpms packages were outdated. In other cases, the flathub flatpaks were using obsolete runtimes, and the apps worked better with them, while Fedora had the newer stuff. In various other cases, it was just upstream knee-jerk reactions from people who are unhappy that distributions exist. And finally, in some cases, Fedora flatpaks were indeed worse for various reasons. Overall, we don't have any good statistics about this.

It doesn't even matter whether the apps are low quality or high quality. What matters is that Flatpak users expect to receive apps directly from upstream, not via Fedora. Fighting against that expectation is not strategic and won't work.

It doesn't even matter whether the apps are low quality or high quality.

I cannot disagree with this any harder.

What matters is that Flatpak users expect to receive apps directly from upstream, not via Fedora. Fighting against that expectation is not strategic and won't work.

Users' expectations are that if Fedora offers them an application, it will work well on Fedora. Throwing up our hands and deciding that "whatever upstream drops on the user is fine" is not something I will support. We can - and must - do better than that.

There is definitely room for improvement on both the Fedora side and the Flathub side and I'm optimistic we can discover a way to improve things.

From my own personal perspective (with my FESCo hat on, but not representing the Will of the Council as a whole):

• As a distributor of software, we have an obligation to our users to validate what we provide in some way. This does not necessarily mean that it has to be built directly by us, but it does mean that at some point Fedora needs to evaluate the delivery pipeline of any application we ship. For RPMs, this means building everything in Koji, which can and is regularly audited for vulnerabilities and intrusions. We have this as well for Flatpaks built in the Fedora infrastructure. For Flathub, it might be sufficient for us to perform an audit on the build infrastructure provided by that tool and certify it in some (cryptographically-verifiable) way that software provided by it that is fully built in that environment carries Fedora's "Seal of Approval".
• We need to offer some applications by default, including on Live media. Anything we ship directly to users must be vetted by Fedora. We are responsible legally - but also morally - to ship acceptable content.
• Despite how we ourselves may feel about the subject, the purpose of an Operating System is to run applications. We cannot forget that. Users want applications available on their system so that they can perform their task of choice. If Fedora cannot provide a solution for them, they will go elsewhere. If the reason Fedora cannot do so is a philosophical one rather than a legal one (e.g. an application is freely distributable but the source is not available or not buildable), there should be an acceptable location to acquire it that Fedora may recommend (or at least minimize the hurdles to activating it). Such content should be readily available but should not carry the aforementioned "Seal of Approval".
• Some content that is acceptable in other locales cannot be shipped by Fedora due to US legal reasons. This content should be available somewhere and Fedora should be willing to enable it.

Right now, the only way to acquire the metaphorical "Seal of Approval" is to be built by Fedora infrastructure. This at least I think we could come up with a way to compromise. FESCo could establish a set of rules that, if Flathub complies with them, we can at least provide a signature for that content. We could then opt to allow any signed Flathub content to be available by default in Fedora, possibly even used on install media (this will certainly require more thought than I am putting into this message right now).

Let's put this on the agenda for today again. We need to make some decision.

My idea from last week was soundly rejected by the folks over at Fedora Discussion, so I'm going to withdraw it from consideration.

The current state of Flatpaks in Fedora is "Bad". From what I can tell, the proposal listed in this Change is "At least as Bad". So I suppose I'm -1 for making any change at all at this time.

FTR I welcome any constructive discussions about areas for improvement in fedora flatpaks by those genuinely interested in their success, but I hope that this is the end of such anti-proposals.

This was discussed during today's meeting:
REJECTED (0, 1, -6)