This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.
Sweeping package management problems under a rug doesn't actually make them go away.
Anybody have a list of open source solutions here?
This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
Yeah, that's like the poster child of sandboxing; I am very much supposing that my word processor is not allowed to touch arbitrary files.
RHEL RPMs are signed by Red Hat. Flatpaks are signed by... whoever happens to maintain that flatpak.
But at any rate the multiple runtimes with multiple upstreams are why it's a non-starter from a security PoV; the uselessness of sandboxing is more just icing.
Realistically, I know that I do not have the skills to evaluate complicated applications and their complicated dependencies for security characteristics, so I am 100% reliant on packagers, maintainers, etc. for my security anyway. I'd rather just donate to the people publishing and maintaining the packages and hope that they are doing the job well, than fruitlessly attempt to fuss over it myself.
The good news is there is a solution to this. The trusted system shows a file picker, and then grants access to the sandboxes application.
This is called the File Chooser Portal. https://docs.flatpak.org/en/latest/portal-api-reference.html...
I suppose additional security features inspired by mobile systems couldn't hurt either. Like a pop-up whenever something accesses the clipboard.
I just hope flatpak sandboxing works well...
Besides, why 2 KDE AND 2 Gnome versions would be needed. The 'minimal' freedesktop would most likely suffice.
Now, it's possible to build my own flatpaks and keep everything updated, but if I'm doing that I might as well just build the actual software and use the distro's package management system.
It does make sense for at least one distro to be offering this, as there are numerous reasons to favor the traditional linux distro way of doing things. Flatpak is better for a lot of use cases, but it's missing a lot by not having a centralized system of checks and balances provided by a Linux distro.
Fedora Flatpak brings back a lot of the advantages of traditional Linux distributions, but unfortunately Fedora/RHEL likely won't be maintaining a Fedora Flatpak version of LibreOffice.
Distribution packages:
+ necessary for base system
+ small memory requirement
+ small package size
+ all checked by distro
+ work well together
+ on fix, fixes it for all
o lot of work for maintainers downstream
- bugs hard to figure out for upstream
- problematic with closed-source
+ programmer packages is/her software once and only once
+ support all distributions i.e. Linux
+ use selected dependencies
+ control-groups and namespace are in place for lock-in
+ autonomous offline package handling e.g. “storeable on thumbdrive”
- huge maintenance burden, especially security, on programmer
- higher memory usage
- big package size
I think Flatpak is ideal for new stuff and especially closes-source software. Programmers cannot do the repeated error of supporting some special outdated distributions. It is a miracle to me how anyone can think that packing for a specific distro is their job? It is not. The job is documenting how to package the software and allow redistribution. With Flatpak we allow them to do package themself if desired but just once and for all.
A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find?
And I don’t want to hype Flatpak: GNOME-Software could use less memory itself, we need an easy approach for payment (and repeated payment?) and it stores many small file on disk. And I wonder which security requirements the Flathub requires?
I think the mentality of authors who package their projects for a specific distro comes from their familiarity with Windows, where there is only one distribution (more or less) and packaging for it is naturally the responsibility of software authors. They mistakenly apply their windows experience to the new task, probably entirely unaware of the faux pas.
Often, knowing that there are a myriad of Linux distros, they mistakenly assume that the community of linux users are expecting them to support dozens of distros individually, testing on each one, and they become reasonably upset with that (mistaken) obligation. So they stamp their foot down and say "I support Ubuntu 13.04 specifically but if you use another distro then you're on your own!!" Then they go on to complain about fragmentation and say that linux users need to pick one distro and stick with it. Really, nobody expected them to support any specific linux distro in the first place but that is poorly communicated to otherwise experienced programmers who are new to linux.
I did wonder how even companies like Amazon came up with that approach? For example their own MP3-Downloader back then. So someone else has written “clamz”. Even Valve was on that train with Steam, first only shipped for Ubuntu until Arch and others nudged them and asked them “to allow redistribution.”. At least this shows, talking to each other helps :) And now Valve uses itself Arch ^^
Hey now, Canonical provides valuable service of researching how to not do something so others can avoid those mistakes.
Desktop portals are not "workarounds", they are the new correct APIs to use
>Portals are the framework for securely accessing resources from outside an application sandbox. They provide a range of common features to applications, including: Determining network status, opening a file with a file chooser, opening URIs, taking screenshots and screencasts [...]
https://lwn.net/Articles/694291/
All things being containerized messes up which require workarounds. xdg desktop portal attempts to provide these but most of the time it fails to do so fully.
Until it gets different leadership. The drive to try to keep creating moats around Ubuntu that only benefit Canonical comes from the top.
I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honestly befuddled. Granted a quick Google search does show the situation has improved a bit in the past year.
I imagine if you're trying to package a Zig or Clojure application it's going to be a lot of figuring things out on your own
The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so.
That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion.
So yeah, Linux app distribution is a pain no matter what it seems.
But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched?
> unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers.
Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done.
If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure.
So I feel parent's point had everything to do with dynamic vs. static linkage.
Bugs discovered in older version of libraries are far more common than newly introduced ones.
Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"
For package managers, difference is how often the decision to update a library must be made. Dynamic libraries mean that the package maintainer of libFOO must be aware of security issues in libFOO, and update accordingly. Static libraries or AppImages mean that the package maintainer of every user of liBFOO must be aware of security updates in libFOO, which is a much higher burden.
Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions.
In my case it was OpenSSL loading stuff at runtime.
But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive dependencies. That's just the sad reality of shipping programs that are dynamically linked.
Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every library your direct dependencies load.
And then everything may still work until 3 distro releases later something finally becomes binary incompatible.
And also the situation isn't really different on Windows except that you have to do it from the start because there is no illusion of the base system providing a bunch of random libraries for you.
It was a pain doing packages 25 years ago, comparatively it is simple now.
Frankly, the flatpak will have issues as well, but those will be outside of Redhat's direct control.
Which means the end game, will be a redhat flatpak.
Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory.
Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?
Also, Flatpak apps are containerized. That usually means they aren't bare metal.