Article doesn’t mention my biggest problem with flatpaks, that the packages are not digitally signed. All major Linux distros sign their packages, and flathub should too. I would prefer to see digital signatures from both flathub and the package’s maintainer. I don’t believe flathub has either one currently.
It is possible to sign a flatpak, but yeah distributors need to actually do that and flathub should require published flatpaks to be signed.
What would they sign it with? How do you verify the signature?
F-Droid seems to manage it just fine. It’s even got reproducible builds.
Mozilla, for example, would sign Firefox’s flatpak with a PGP key that they would disclose on their website. You verify the signature using the RSA algorithm (or any other algorithm for digital signatures. There are a bunch.) Or, you could just trust that your connection wasn’t tampered the first time, then you would have the public key, and it would verify each time that the package came from that same person. Currently, you have to trust every time that your connection isn’t tampered.
Major flatpak providers (Flathub at the very least) would include their PGP public key in the flatpak software repo, and operating system vendors would distribute that key in the flatpak infrastructure for their operating system, which itself is signed by the operating system’s key.
that they would disclose on their website
Wouldn’t it make more sense then for them to simply host the Flatpak themselves? I kind of thought that was the whole idea of Flatpak.
deleted by creator
deleted by creator
Guess my next GPU will be AMD
Flatpak is quite fucking far from perfect, and will always remain so due to its flawed design and UX approach.
Pretty sure the culprit here is Fedora’s packaging which adds an opaque systemd timer to run auto-updates, but the thread immediately next to this one on my homepage just happened to be a nice case-study in Flatpak fuckery: https://lemmy.world/post/30654407
Of course, the proposed changes in the article do nothing to fix this sorta problem, which happens to be the variety that end users actually care about. Flatpak is an epic noob trap since it pretends to be a plug-n-play beginner friendly tool, but causes all sorts of subtle headaches that newcomers inevitably don’t have diagnostic experience to address.
The problem of there being a separate runtime for each video driver version was explicitly discussed in the article:
If you are part of the huge part of the population who happens to own a Nvidia GPU, it’s a whole other can of worms. There are Flatpak runtimes that target specific Nvidia driver versions, but they must be matched with a compatible version installed on the host system, and it is not always a process as smooth and painless as one would hope.
An improvement idea that is floating around is to, basically, just take a step back and load the host drivers directly into the runtime, rather than shipping a specific version of the userspace drivers along with the application. Technically, it is possible: Valve’s Linux runtime is pretty similar to Flatpak architecturally, and they solved this problem from its inception by using a library called libcapsule to load the natively installed host drivers into the Steam Runtime. This is the reason why it’s significantly rarer that an old Steam game fails to launch on a new GPU, compared to the same scenario on Flatpak!
I really think if flatpaks were built upon nix, it would resolve these problems. It would however bring a new problem: people would have to learn forsaken nix 💀
It’s not clear that it would, because the root problem is locking a package to a particular version of the nvidia drivers, which nix would not solve. Unless I am missing something?
Ah - I totally missed the Nvidia-related bit! Thanks for flagging that.
That being said, based on the maintainers’ past stances, I’m pretty pessimistic on them actually implementing a fix like that. They’re very much against the general practice of poking holes in their sandbox security perimeter.
