Sandboxing isn’t a tech demo. Yes, it’s not perfect. No, it doesn’t mean it’s inferior.
2 Likes
Which ones specifically? I only heard of OBS a little while back.
2 Likes
Every single Fedora flatpak basically. There’s around 100 apps packaged there.
Are they non-functional? Or what’s badly packaged about them?
2 Likes
Somehow I missed this part. Serious question: how do you think it should be handled? Forcefully updating apps to newer runtime? Or do you have other ideas?
Fractal being badly packaged and losing important functionality (forgot exactly what broke)
Thundebird crashing on startup.
Bottles being unusable.
I have a couple more example, if you want.
The issue was not with the flatpak itself, but the RPM. It was missing a dependency related to image rendering. The problem mainly manifested in the flatpak because it only has access to things in the runtime and vendored dependencies.
This problem could have manifested on non-flatpak installs too, such as if using a minimal desktop that doesn’t have Gnome dependencies.
Correct.
Bottles was never packaged as a Fedora Flatpak. It was the RPM that was broken. And yes, this is still bad, but not related to Fedora Flatpaks directly.
2 Likes
It’s a difficult problem to solve.
I think one of Flathub’s unwritten goals is to make working with and packaging on Flathub as easy as possible. Stricter security measures would increase the barrier to entry and may scare away some developers (espeically proprietary app developers who don’t have the greatest Linux support).
Forcing runtime upgrades are a bad idea. It will work some of the time, but doing something like that automatically and without human testing from a responsible party would break things.
In the OBS case, it would have helped if the KDE runtime were supported longer. While freedesktop runtimes are supported for 2 years, I believe KDE’s runtimes based on the freedesktop runtimes are only supported for a about a year.
But even then, just supporting runtimes longer is not the answer. Many developers are lazy and will wait until the last minute to update things. It’s kinda scary how many things on the Snap Store are using such old runtimes just because they can (especially annoyed me that my password manager was using a runtime from 2018 when the current year was 2024).
Then there are cases of apps that are just abandoned. I don’t think they should be removed from the store, but I think they should be hidden by default. That could mean hitting a button to show old, unsupported apps with a warning or not showing them at all, requiring a CLI command to install them.
2 Likes
I still maintain if I ever get into Flatpak, I like the idea of Fedora’s repo on Fedora more than Flathub!
5 Likes
It’s not the case at all. There are many app requests (or how its called) that were rejected. What you heard previous FPL say that Flathub’s rules are lax is a full-blown lie.
The moment package is approved in Fedora, maintainer can do whatever they want, because it’s not monitored. With Flathub, every change in permission must be explained and approved by app reviewers. And no, it’s not “wild west”. Verified can mean that person/person trusted by upstream is maintaining the app. BTW, pot, please meet the kettle 
Just saying, but just because some Fedora packager touched something doesn’t mean it’s suddenly blessed.
3 Likes
It wouldn’t be a Fedora Discussion thread if there wasn’t rampant misinformation repeated for the 300th time after it was disproven.
8 Likes
Hey, so lets talk about it.
I’m going to firmly put my Fedora Project leader hat on my head right now.. so everyone is clear that I am speaking as the Fedora Project Leader…
First let me say that I’ve been unable to talk about flathub specifically for the last 3 months or so because I found a very significant copyright license violation problem with the flatpak runtimes they host while I was attending GUADEC in my capacity as a GNOME Advisory board member. I spent some amount of time communicating back channels, quietly with the goal of making sure that problem got fixed and tried to make sure everyone involved felt like they had space to get it solved without feeling like I was going to throw them under the bus publicly for making a mistake with the license compliance.
If I had wanted to have an actively hostile relationship between Fedora and Flathub I would have made my findings public and dragged them for 3 months in social media while they sorted out the problem. I could have stood up in front of the entire collected group of GNOME developers and made some very opinioned statements that would have probably torn the relationship asunder for years. I didn’t. Nor did I slink a way to the relative safety of social media to outrage farm at their expense. I didn’t. Instead I had some quiet conversations with people in positions to effect change, and got them to acknowledge the problem existed, and gave them my assurance I would give them the time to address it… because mistakes happen.. and its important to get it addressed.
Sometimes, a lot of the time, playing nice means having quiet conversations about the difficult topics, instead of pulling out the eye poking stick at every single opportunity and jabbing other people in the eye publicly. I definitely poked some people in the eye, but I did it in private in an effort to keep future opportunities open. So when you make a call for playing nice… know one thing… I have been.
There are more things I’m going to be doing in my capacity as GNOME Advisory board member that will involve playing nice in a similarly less public capacity. But now that flathub has made a public statement about the license compliance problem I found and reported, I’m able to play nice in public now too. If you want me to talk more about the details of the compliance problems I found.. I’m happy to.. now that they’ve made a public statement and addressed them. From my point of view, they’ve made progress and there’s more to be done. Talking about it publicly specifically to score points off of them is explicitly not something I’m interested in doing.
Moving on… lets talk about Fedora flatpaks. I would love nothing more than to be able to make the case that Fedora can set aside this work.. and stand up flathub as a trusted partner but here is what I need to be able to do that.
- I have to have a way to address the inherent liability associated with license compliance from a distributor point of view for any flatpaks that Fedora pre-installs as part of any composed images. The 3 months it took for flathub to address the compliance problems I found this summer puts an exclamation point on this. I can’t live with a response time like that for the runtimes that multiple applications depend on. I know the leaders of other distribution projects have come to the conclusion that they can live with it.. but Fedora can’t. If you can’t respect the self-assessment that Fedora has a higher risk profile than either flathub or other projects that depend on flathub.. then I don’t really know what to tell you… you’re gonna have to agree to disagree on that. If you do accept that Fedora has a higher risk profile for the liability associated with license compliance and you still think Fedora can shutdown its own flatpaks in favor of flathub.. you’re gonna have to explain to me how that’s gonna work the next time there is a compliance problem at flathub and it takes them months to fix.
If flathub fails, for whatever reason, to address acknowledged, license compliance issues with a certain timeframe (that we need to come to agreement on) Fedora, as a downstream distributor, needs to have an out, where Fedora can take control and address the compliance risk by issuing replacement flatpaks builds under Fedora’s control. Every distributor makes its own risk assessment and it really doesn’t matter if other things out there feel comfortable baking in Flathub flatpaks into their images, end of the day, flathub isn’t a liability shield for the license compliance risk to Fedora for things baked into Fedora images. This is my top priority to solve. If there is no other workable solution to the liability problem, Fedora has to keep building and distributing its own flatpaks.
I can’t stress this enough… license compliance isn’t like security issues. We live in a no warranty world and while security issues are problematic for users and have reputation damage burn associated with them.. there is no actual legal liability at present with not addressing them. The CRA may impact that assessment soon…but not yet.
License compliance is sort of the exact opposite. Users generally don’t care (A few do) , but there is legal liability for Fedora as a distributor… and I as FPL have to take that into account. And the only way right now that I see is that Fedora continues to build the flatpaks for anything it wants to preinstall into deliverable images. We don’t have to build them the way we are building them now, but we may still have to build them if we distribute them to ensure we can mitigate our own liability. Give me another option to address the inherent liability associated with license compliance that doesn’t make the Fedora project wait 3 months for flathub…which is frankly unacceptable.
- Fedora needs flatpaks on architectures that flathub doesn’t provide support for. This will likely become more pressing in the near future because we may end up in a world where we have deliverable RISC-V desktop like bootc environments ahead of flathub servicing RISC-V. We already have some differences for ARM that makes depending on flathub difficult because flathub lets individual projects choose which architectures they support. Flathub is allowed to do that, they control their policy, but that creates gaps for Fedora users using anything but x86_64 arch…sometimes in places that are quite noticeable. I have no idea how to fix that other than having Fedora build its own flatpaks. RISC-V enablement puts significant pressure on Fedora to keep building its own flatpaks.
Person opinion..
part of the problem here is that flatpak as a technology is way more expressive as a commandline tool than how it presented to desktop users. I can actually prototype some interesting examples using the commandline tool that doesn’t translate to the desktop user experience right now.
I think what’s really needed here is some acknowledgement from the UI developers that there is some compromise needed to have flatpak capabilities surface up to the users in some different ways. There maybe a way out of some of this using flatpaks installations concept.. but its not surfacable to end-users right now.. or at least I don’t see how to.
10 Likes
and @kylegospo
That’s not what I’m referring to.
Flathub has a really good first initial review process. It ensures the app has high quality metadata, is using a supported runtime, has a good set of default permissions. Has real humans involved. Far better than the Snap Store.
The issue I’m referring to is after that fact, years later. If your app becomes unmaintained and/or EOL, it just sits there on the store. They never take down your app, they never never hide the app, etc.
You can see details about how many apps are visible on Flathub that are using EOL runtimes here: https://flathub.org/en/statistics
2 Likes
With the CRA coming into effect soon… there may be some expected behavior around EOL’d runtimes. I could argue, and probably will argue that continuing to publish new app builds against EOL’d runtimes is counter to spirit of the CRA’s intent. And having flathub continuing to allowthat, may jeopordize the CRA carve out granted to open software stewards and its in the best interest of the ecosystem if flathub stopped allowing that.
But that’s a speculative opinion on my part that surfaces my unease with the CRA at present.
As a more concrete example based in the now, I know on Android.. old applications in the play store that do not confirm to a minimum version of the play sdk… android will refuse to let me, as a user, download and install them to my phone. That seems a prudent approach for a centralized software store to protect users from old junk making use of EOL’d SDKs that will never get a security fix again. Not sure how flatpak as a technology would be able to let remotes like flathub encode those sorts of rules. But I guess anything is possible with the correct metadata constructs. That’s more of a flatpak feature that would need to be developed, that remotes could make use of.
2 Likes
It’s interesting, because Nautilus on Flathub had the same issue. It was really old version and was flatpak itself was unmaintained, Peter (one of Nautilus’s maintainers) asked for it to be taken down, and in turn received an answer that the only case where any app is taken down, is for legal reasons. Otherwise, it’s just hidden. And it’s true! The only way to install EoL Nautilus is through command line. Which is the way most users are not going to use. Software/Discover are not going to show it. Whether it’s good solution or not, I’m not going to be a judge on that, however, it *has to be* taken into consideration.
Quoting that here but really, this is a reply to your entire post:
I submitted the Filter Fedora Flatpaks for Atomic Desktops specifically so that we don’t have the problems that you describe here:
- We offer Fedora Flatpaks only where it makes sense, notably for shipping on the ISO
- We build for arches that Flathub does not cover
It got rejected.
7 Likes
I am aware.
However… Fedora as a big tent effort can grow an unbounded set of preinstalled items because we will have spins and remixes… not just the flagship editions.
As soon as I have to build any flatpaks I have to build all possible flatpaks and anticipate they will be preinstalled in something in the future. The filter papers over a fundamental problem under the assumption that the flagship outputs are the only thing that will present liability.
I’m going to ask you as a Fedora Project Leader, would you be willing to actively work with Flathub to make sure to resolve this in any way? Otherwise this whole statement is useless if the course of action is still going to be “Fedora flatpaks all the way“.
Slightly unrelated, but please avoid saying this xD After Framework situation this word doesn’t sound the way you probably intended it.
2 Likes
“I’m going to ask you as a Fedora Project Leader, would you be willing to actively work with Flathub to make sure to resolve this in any way?”
do you think I was looking at the internals of the flatpak runtimes for fun when I found the compliance problem?
I’m trying to build a bridge so we can be in a more coopetition relationship than we have now… it sure would help if everyone else holding the torches would take a break from setting fire to the supports.so I could spend more time building instead of putting out fires.
7 Likes