Proposal: Enable Flathub by Default

Project Discussion
, ,
123

Yes and no. Yes, because I do use their software and no, because I do use flatpaks.

I’m sorry that I’m not gonna address all of your comment (it’s, um, a lot of text and i’m extremely tired), but my point essentially boils down to: apps using EOL runtime are not a serious issue. It’s a minority and if app is really old (just like it happened with Nautilus on Flathub) users would only be able to download it via CLI. What happened with OBS was an unfortunate situation, but to say something as if the app was badly maintained (or other similar things that were said) is just cruel. Note that it was indeed a temporary solution and since some version (idr which one) OBS is back to using latest runtime.

Banner informing users that the runtime is EOL in GNOME Software is indeed lacking, but maybe there will be some volunteer willing to send a patch fixing this.

its almost 2 o clock, so please excuse my spelling and/or my grammar. hopefully i succeeded at conveying what i wanted to say

124

is it a minority? I think that’s an assumption.

What if I told you that there were at least 1000 apps at flathub that are using EOL’d runtimes? Would you consider that insiginficant?

without a concise list of what the currently supported runtimes are I can’t do a full accounting. And that list doesn’t exist as a documented artifact of flathub policy afaict, and the tooling doesn’t let me discover what is EOL’d what is not afaict, othe than by trying to install everything one by one and recordingly which flatpaks trigger a warning message.

But just looking at the stats page for flathub and doing something naive like counting up everything running an older version of any versioned runtime as potentially an issue then the numbers add up to be a significant percentage of the flatpaks. But that’s not accurate enough. because what matters is which of those flatpaks have been updated since their runtimes went EOL.. and I can’t get that from the stats page because it doesnt give a sense at all of what flatpaks are being actively updated and which ones have gone inactive.

I’d like to do an accurate accounting what the state of things are.. but its not clear to me if there is a way to ask the tooling for the information necessary to get solid numbers using a methodology that others can repeat for themselves.

125

Hey Jef,

You raise a valid concern — the state of runtimes in Flathub deserves better visibility and tooling. But I’d argue that this shouldn’t block enabling Flathub by default for FOSS apps in Fedora.

A few thoughts:

  • Even with the current issues, the value of giving users access to thousands of actively maintained FOSS apps outweighs the downsides of the minority using EOL runtimes — especially when the alternative is no access at all by default.
  • The problem of EOL runtimes exists regardless of whether Flathub is enabled by default. What we can do is help surface that issue better in GNOME Software (as Victoria mentioned), and collaborate upstream on improved metadata or tooling.
  • Fedora enabling the FOSS-only filtered Flathub could actually push momentum toward cleaning things up, by putting more eyes on the problem from a more diverse user base.
  • In the case of OBS and others, things did get resolved — and that’s good! But many users don’t know Flathub even exists or how to enable it, so they never even get that far.

The toggle to enable full Flathub (for nonfree apps) would still be present post-installation and in GNOME Software, just as it is today.

So in short: yes, the EOL runtime issue is real — but solvable — and not a strong enough reason to block Flathub (FOSS) from being default, which is a necessary step for usability, interop, and the future of Flatpak-based systems like Atomic desktops.

Thanks for raising the quality concerns — let’s keep pushing for better tooling and better defaults.

126

You are wrong. Use of an unmaintained runtime is dangerous and irresponsible professional malpractice. This is a very serious issue. Flathub needs stricter rules before this proposal to enable it by default should be accepted. E.g. Flathub previously prevented developers from releasing app updates if the runtime was unmaintained; simply resurrecting that rule would be a pretty good start.

OBS Studio was a particularly egregious case, one that unfortunately significantly undermined my faith in app developers. The excuses for why it could not use a maintained runtime were unacceptable, and citing it as an example helps my argument, not yours.

Possibly, but my goal is to improve Flathub, so I certainly don’t want to ignore the problem. We should solve this before enabling it in Fedora.

2 Likes
127

Do you also have this opinion on LTS distros like Debian or RHEL? Because packages there are essentially also frozen in time.

128

I held a talk indirectly related to this at the last Fedora London Meetup, but from the perspective of economics/competition and social dynamics :nerd_face:

It is indeed not a good idea to ignore that, and I agree with Michael for economic reasons: if we create/keep the condition that issues have to be solved before a big community like Fedora (effectively) migrates in its flatpaks, we create incentives to solve the problem, and of course that should go along with helping to solve the problem and provide solutions (obviously there is a reason why they do not yet solved that).

But if we just migrate, there is no longer an incentive to solve the issue from us, and the immediate emphasis might (maybe even needs to) shift to other problems (such as getting the next community on board as Fedora is considered a “done” task). However, the next community in focus might then also deploy a focus more on “getting more users respectively packagers on board through more respectively easier-provided apps” rather than consider security issues. And so on and so on → that way, this issue will remain on the To Do list, maybe even of everyone, but it remains untackled and unsolved, as it never comes into emphasis (every entity will always focus their resources on their perceived most critical problem).

That said, we also have issues in Fedora in our packaging, and as much as I trust the packages that are reviewed or maintained by the big WG (and I consider KDE here practically as a WG), we leave the path of reliability when we end up at the packages that are 1 of 2000 of one maintainer, who might not identify the issue when their automated pipeline is broken. I don’t know how many packages I have over time identified that have not been updated sometimes for years, in one case one with a CVE (though a minor one). Not sure if the LXQt spin got in the meantime an update to a LXQt environment that is maintained rather than an obsoleted version of LXQt.

So with all that in mind, I could imagine that flathub is the future, and its problems might be easier solved from a holistic point of view than that of Fedora packaging (including the amount of packages and the pressures to often keep stuff that we cannot reliably maintain due to lack of personnel contributions while users are being expected to want them), and it is worth to support flathub and set the goal to make flatpaks defaulted to them, but I don’t think we should bypass issues as those mentioned here.

By the way, I am just testing flatpak since a few days (I am completely new to that so I am careful with involving myself too deep into this conversations given a lack of flatpak experience and lack of time to read all policies around it), and beyond the warning of obsoleted runtimes, I still get no warning if a package is not verified (unless I know how and where to search, have sufficient background of such technologies and therefore end up and read the page in order to get to know --subset=verified). I think the unverified issue is indirectly already part of the conversation through some of the comments above (e.g., the comments related to always use the source), but I thought it might be mentioned more explicitly for once. That issue imho should be on the “to do before migrate” list too (and, e.g., if flathub use increases throughout communities while having means to discourage installation of unverified flatpaks: having in that situation no verified VLC, as at the moment, might also put some incentives for the VLC maintainers/community to provide a verified version to get their product back in use rather than accepting a third-party-bad-practice-solution that then would cause a decreasing use of VLC because “unverified”)

I am aware that I simplify some things, but I thought it might be useful to add these points to be considered more explicitly at least on a superficial level :classic_smiley: Anyway, thanks everyone for the interesting thoughts and the constructive conversation, I try to keep skimming through it, as much as I can spare time :slight_smile: (you might forgive me if I accidentally repeated something already mentioned, I could only skim through the 125 posts :frowning: )

2 Likes
129

At the same time, i have run into at least two cases in the last year where an official Fedora package was not actively maintained for over 6 months, and was 10+ releases behind an upstream source, which included security patches. The local maintainers received a number of requests to keep the package up to date but simply didn’t do so. These packages continued to be installable from the main repos and in some cases caused some real problems for users.

So do we have any certainty about Fedora packages themselves being maintained and secure? It doesn’t appear to be the case in the current circumstances. If someone is listed as maintainer but doesn’t do their job, things will generally just linger on until they actively resign, which can take up to a year or longer.

It made me think differently about how much i trust the official repos to be safe and up to date.

6 Likes
130

LTS distros are inherently dangerous, but they all fortunately have security teams watching for CVEs. But you should worry about all the security vulnerabilities which do not receive CVEs. My guess is that only 15% of security vulnerabilities receive a CVE, though it’s impossible to know whether my guess is correct, and this number will vary considerably by project. My recommendation: if you use an LTS distro, do so for a relatively short period of time, say 3-4 years. This way, all those vulnerabilities that did not receive CVEs at least get fixed every few years. Also, it’s important to understand the scope of the distro’s security commitments. (E.g. Ubuntu guarantees CVE fixes only in the main repo, not in universe; if you want CVE fixes in universe, then you must pay for Ubuntu Pro.)

In contrast, an EOL runtime does not ever receive any updates whatsoever.

I would not warn users if an app is not verified. That’s probably too strict. Whether upstream is providing or endorsing the Flathub packaging makes little difference to me.

I’m not at all surprised. It’s also very common for Fedora packagers to ignore CVE bug reports. We have an unresponsive maintainer policy that should help in situations like this, but somebody has to notice and invoke it. And it only helps end users if a new maintainer steps up to take over.

I wouldn’t count this as an advantage for Flathub, though, because I’ve noticed the same problem on Flathub as well. Perhaps both of our communities need an easier way for flagging a package as unhealthy. Arch has an easy mechanism for flagging a package as outdated, for example.

3 Likes
131

I do not necessarily disagree. But what I criticize is what “unverified” can mean, directly or indirectly: for flathub, it seems to have a meaning that can differ among contexts, as in different contexts, it can have different impacts. In some cases, I agree that we do not need to confuse users about it. But in others, I remain more critical: I dislike the possibility for having both on one hand an flathub-maintenance-entity I do not know (it is not yet clear to me if the social dynamics of the flathub community practically facilitate “github accounts” “without further questions”), and on the other hand a package that does not come from its source. In some circumstances, I can live with one of the two: e.g., I am fine that Mozilla uses their own pipeline - I can understand that this might bring advantages, and I cannot use Firefox without trusting Mozilla to some extent anyway. I’m fine with that. But when the combination of the two issues comes together (third party maintainer/unverified at flathub + not from source), I see a high potential for issues up to abuse ( → at least through complexity ).

What I read around flathub documentation is partly abstract, and since I just started with it a few days ago, I might missed if some things are solved in practice, but so far, I see no explicit guarantee that these two issues do not come together. So that’s what makes me worry about “unverified” → if it is unverified, do I know that by some other means it is ensured to come from source?

It also feels harder to track down a flathub package’s background/implications in a reliable/reproducible way, compared to one at Fedora, though I just started with Flathub a few days ago but know the pipelines of Fedora for years, so that might be a highly biased feeling of mine for now :classic_smiley:

Again, I see the potential for these issues to be solved, and I see more potential for Flathub to solve its issues than at the moment at the Fedora packages that are not maintained or reviewed/verified/observed by the WGs (here I include again the KDE SIG), but so far, I would not replace the Fedora repos by default, for the reasons I elaborated in my earlier+this post.

I already mentioned that here and in my earlier post indirectly, but I would say: yes, if the packages are shipped by default by any official edition because that implies the WGs are ensuring these are maintained properly. In short, the WGs mitigate single points of failure and ensure a lot of review also through their involvements, reviews and collaborations and integration with QA. I see no realistic issue to rise there. But once you leave the realm of the packages they ship by default or that they involve due to widespread or potential future use: I agree, and if you want to have security here, you need to keep in mind what further packages you have installed and review yourself that they remain properly maintained. I indeed do that. Though it also makes sense to check out who maintains your preferred packages and/or who is involved. Not just those of the WGs can be trusted for reliable maintenance. There are more packages that are well maintained and reviewed by major developers and teams, or directly/indirectly reviewed by them. But once you leave the default packages, you have to check out what you install and who maintains it: the Fedora repo does not ship with the holistic guarantees over all contained packages we would like it to ship.

132

I think one thing that seems like it’s missed in these discussions is
that it’s more nuanced than that.

In the case of bottles or obs you have upstream projects that produce
flatpaks as a main deliverable, test it, make sure it’s working and
point users to it. In this sort of case it may make sense to not provide
a fedora flatpak.

However there’s a bunch of other cases too:

There’s no flathub flatpak for something, but there’s a fedora one.

There is a flathub flatpak but it’s just a CI artifact or something that
the upstream project doesn’t particularly test or advertise

Or in between where there might be a community maintained flathub
flatpak thats better than the fedora one or vice versa.

133

Here nuance only matters to the extent that it can be algorithmically computed. Our software centers can implement algorithms to decide which software source to select by default… though if we make the rules too complicated, users will become confused, so simpler is better. We probably don’t want to be making decisions about app software sources on a case-by-case basis. And we certainly don’t want to force the user to decide which software source to use when installing an app.

134

I’m not convinced that app developers are incentivized correctly to stop using EOL’d runtimes. I’m concern is that the build policy as it stands would only result in increased use of EOL’d runtimes over time, not less.

Having to build against supported SDK versions is not an unexpected requirement for app developers using an app store in my experience. Apple does it for its iOS store, Google does it for Google Play for Android. And for good reason, if they didn’t require it as a matter of policy, then application developers just wouldn’t do it, because they are not incentived to do it on their own. I see no reason to expect it to be different for a default Linux desktop app store.

I would encourage you to read the information explaining the rationale behind the Google Play Target API level requirement that forces app developers to update against supported SDK versions.

2 Likes
135

Is there any proposal made to Flathub to improve current behaviour?

136

I have no idea.

Let me know if you find a Flathub discussion.

137

Are Flatpak apps guaranteed to run on any OS that has the system/set-up for it? Or is there any case of a Flatpak running on like Arch and nix but not Fedora?

  • I generally feel not using a traditional package format for the distro is 3rd-party; Fedora Workstation is rpms through dnf primarily, with GNOME Software and Flatpak + etc as 3rd-party.

  • With that, it feels like a frontend + Flatpak is like a 3rd-party app store on Android or iOS. Both don’t like 3rd-party app stores; both have their own stores with traditional packaging (Android apks, iOS I haven’t seen an app with extension :stuck_out_tongue:). Both generally allow 3rd-party app stores, with apps coming from there having some note it didn’t come from the device’s official store (Android 14 tells me an apk “App installed from Files”, vs “App installed from Google Play Store”).

  • I feel Atomics/immutable is a different concept than Workstation. While I expect traditional packaging on Workstation, I’m generally fine with Atomic being different and prioritizing Flatpak instead of traditional packaging, but I also don’t have reason to use an Atomic distro.

  • Allowing EOL anything to be packaged by an app in a user-side app store shouldn’t be allowed; it encourages lazy behavior at the cost of security (shouldn’t be softened because security, but it allows a convenience by letting apps ship with runtimes already-determined to be end-of-supported). I’m kind-of ok with this with 3rd-party phone app stores (it’s already unsupported/at my own risk and I can vet stuff after that). I can’t quite entertain this on what’s supposed to be a secure operating system on a PC I use for more important manners. Even if I take note to not have EOL runtimes on my PC, it doesn’t inspire confidence that an app store allows it as a convenience. Flathub’s (apparently) lax procedures clash with Fedora’s security imo.

  • Flathub is larger than Fedora’s Flatpak repo: If Fedora’s repos allowed EOL runtimes, I’d have less issue (I trust Fedora’s security process over Flathub; Fedora’s a secure OS vs Flathub as a software-acquiring convenience).

I don’t like the idea of Flathub enabled by-default on Workstation and would disable it. I can’t really go on a position though (the idea is wild; I have an easy-disable solution, but have some concern of resources dedicated to this on an OS as a larger-picture vs something else I find more beneficial, but it’s volunteer/free-to-work-on-anything-wanted so :person_shrugging:)

138

Thats the subset i want…

But i would also like a verified can be proprietary and not build from source but foss is always build from source (and also verified)

So the user can be sure foss = build from source, but proprietary is available, and for obvious reasons not build from source, but at least packaged by its creator (verified)

139

I always assumed, dependencies would be in the runtime not the Flatpak app itself

140

Depends on the flatpak. There’s flatpak runtimes, but some runtimes can be bundled into flatpaks as well.

141

This doesn’t make sense. We’re an open source project. Why should we disfavor other app providers in the same way that proprietary platforms (which google play is) do? Flatpaks are also preferable to RPMs in many cases. I mostly use RPMs, but there are some programs where I will actively prefer the flatpak version over the RPM.

1 Like
142

And as a FOSS project, we should never, ever, ever, offer an installation source which is not also (fully) FOSS. I respect those who wish/need to use non-FOSS apps or drivers, but no one should (without explicit agreement and understanding about their explicit agreement to using proprietary codes) be able to install non-FOSS apps without knowing they are giving up on FOSS.