Flatpak: A security nightmare – two years later
flatkill.org
flatkill.org
- You'd expect the application to run as your user and have full access to the home directory. Many applications expect to have this access. This is what it means to have user space applications. Flatpak is not about fixing or changing this.
- You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak.
So, works as advertised and intended. If your flatpak install has security bugs, update it. If you use a linux distribution that ships an out of date flatpak with fixed security issues, consider using a different one or update it yourself. If you use flatpak apps from developers that can't be bothered to release updates or fix bugs, consider using something else.
Basically, flatpak not being a middlemen between you and the application developers kind of is the whole point. They don't mention sandboxing on their frontpage, at all. This is not a goal. Instead, providing a cross distribution consistent installation experience is the main goal. They are not trying to be more secure than manually installing packages on your system.
So, these are not security bugs as far as I can see. It's not a security nightmare. It's fine. Actually looks interesting and might give it a try if/when I get rid of my mac.
If it was a regular application installed by a linux package manager, the dependencies will be automatically updated to fix security issues(At least in most cases).
...and without this "fake sandboxing" strawman, flatkill.org is left without a convincing argument.
The security trade-offs that come with flatpak are the same tradeoffs that desktop operating systems like MacOS and Windows have made since their inception.
Considering that these are successful desktop operating systems, whereas Linux is not, one might conclude that these are the right tradeoffs, all things considered. Sure, it's "a security nightmare", but we've been living through it for decades. The alternatives clearly aren't good enough to bring everyone to move over.
If you can't trust a library author to keep their code up to date, it's probably also a mistake to trust them to use your system libraries in a way that minimizes their attack surface.
I also have problems with Flatpak's security model, particularly with their UX around permissions. We already learned from Android/iOS that allowing highly permissive manifests out of the box was a bad idea. But at least Flatpak is trying to do something, and that something seems like a tangible improvement to me. The idea that our systems will be secure because we dynamically link everything needs to die; it's not a viable security model.
Even if the only thing that Flatpak does is kill the "dynamic libraries make me secure" perspective, that on its own will be worthwhile.
Solaris-style RPath is still an option on Linux, but it is rarely used.
As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible.
Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner.
This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.
That’s a pretty bold claim. Can you identify a specific C program that cannot be built statically, no matter how hard you try?
Well, not sure about C (but I assume something using gtk could be pain), but if we expand that to C++, I mean, I would expect firefox and chrome to be basically unbuildable in static manner.
> no matter how hard you try
Well, no. If you are willing to rewrite it (even significant changes), of course it will be possible to built it statically. That does not mean it is doable in practice.
Add licensing complications to that (Qt is notorious for this) and OP's statement is for all intents and purposes true.
If we were to redo these today, I think we'd do them out-of-process and talk to them over UNIX domain sockets or pipes.
The transitive dependencies of NSS and PAM modules can also wreak havoc with your application. There are many bugs which have arisen because of these limitations. Yes, looking at you, GnuTLS.
as a user of statically-built Qt I haven't noticed any particular breakage
The question about it comes up every so often, but nobody has ever put up the effort to maintain it. It appears to be a lot of work for very little gain.
Static linking is an atavism. Application authors don't spend time thinking about it any more.
The main reason static linking persisted as A Thing into the 1990s was that fossilized vendor UNIXes didn't support it, or didn't support it well. Those systems are all extinct.
About the only place you still see static linking is embedded. And that is its own world.
The golang model expects all golang deps to be distributed as source code, and then it expects to dynamically link to all C dependencies. It is technically possible to diverge from the latter set of expectations, but it is not easily or commonly done.
C++ is much like golang in that respect. Template libraries are always "static" in the sense that they are distributed only as source code, but the final binary output is almost always a dynamically linked binary.
I'm not saying that the UX of native packages is great for end users. I'm just saying that the security model is saner.
Heck, there's a decent amount of Linux software being distributed right now as `tar.gz` files with an install script that just extracts the folder someplace and then modifies the user's path.
Flatpak improves on all of that.
It's one thing to look at the Linux security model and say that OSS authors should coordinate with distros, but OSS authors and general Linux developers already don't do that today. So how is Flatpak making that situation any worse?
Developers were already abandoning the sane security model. Flatpak is a response to that trend, not the cause of it.
I don't have an answer to this question, but I would never do this. If the game was open source, I would rebuild it to be dynamically linked, and then publish the dynamically linked package.
Should we get rid of the AUR while we're killing Flatpak?
The "authors won't keep their own software up to date" point isn't an argument against Flatpak in specific, it's an argument against custom package sources in general.
If we really don't trust authors to update their own software, then we ought to be pushing for even stricter sandboxing and system isolation than what Flatpak currently provides. The cat is already out of the bag: people already run software on their system from the AUR, from private repos, from custom Linux installers that just bundle everything into a tar.gzip. Dynamic linking won't save you from them.
If Ubuntu was the ultimate distributor of every Flatpak and had the means to recompile and update the dependencies for those Flatpaks whenever a security risk was discovered, they wouldn't need Flatpak. They could just maintain the software the way they've always done before.
Consider what the advantages to Flatpak really are.
1. Anyone can publish them (low standard of inclusion, which I hope isn't Ubuntu's goal)
2. You can easily distribute closed-source software with the exact dependencies they were compiled for (which Ubuntu can't change unless they have access to the source code and its maintainers are willing to provide that charity to closed source software shops)
3. You can easily install the software on any system with a recent enough kernel (Ubuntu being the sole provider wouldn't change that)
1. Ease of distribution of software should be a goal on Linux if it's not already. The lack of ease of distribution of software contributes to decreased support from developers on other OSes, increased pressure and stress for distro maintainers, and some truly awful installation methods outside of the official package managers.
2. Proprietary software largely already does this, so granted, using Flatpak doesn't really change anything. But that's also kind of the point; proprietary software already ignores the software center, so adding better sandboxing to those apps is a really good idea.
3. There are reasons to want the ability to link against multiple versions of the same dependency even if you're getting all of your software compiled by a single source upstream. Reconciling dependencies if you're a distro maintainer is hard. Being able to quickly update any app that's using an outdated dependency without worrying that you're going to break another app is kind of nice.
I'm not saying that Flatpaks should be centrally managed. My point was that people are already distributing software outside of app stores. We already have the AUR, we already have `tar.gz` files (even from Open Source projects), we already have custom repos that might break/rename/embed old dependencies.
Flatpak is responding to a trend that already exists; trying to make it slightly better so that instead of a random install script somebody pulls off Github to curl dependencies, they get a well-defined package that's less likely to bork their system or introduce a security hole into their other applications.
And that's good. We want to live in a world where people can install software from any source -- we wouldn't use Linux otherwise. But any system where people can install software from any source is going to have the same issues with dependency management and with trusting the author to keep their app up-to-date. All of the problems people are throwing at Flatpak in that specific area are just criticisms of the fact that Flatpak isn't centrally controlled. They're not really criticisms of the technology itself.
OP has just provided concrete examples of those problems appearing in the real, existing public repos for Flatpak.
This is not surprising.
It has turned out exactly as expected: Upstream developers cannot be trusted to update dependencies on a timely basis.
And the current system, even without Flatpak, doesn't force them to. You're not arguing against Flatpak, you're arguing against decentralized app distribution in general.
You are already living in a world where upstream developers can decide to distribute their software using channels that distro maintainers can't control, update, or patch.
Flatpak changes nothing about that arrangement, it merely acknowledges that the problem exists and tries to make it slightly better. The alternative to Flatpak for a lot of Open Source devs isn't an official Debian package, it's a tar.gz file, which is just objectively worse.
Sidenote: I include docker as a package manager in that list because recently I actually ran into a very large and popular command line application that, per their documentation, prefers distribution and execution via docker over anything else: aws-cli. They don't keep any other linux package managers up to date, despite having a package in snap and distributing a .tar.gz. They recommend invoking it via docker. Rather interesting, and I'm surprised we haven't seen a frontend for "docker as a pm" gain traction, to increase usability over "go into your .bashrc and alias aws=docker run aws/aws-cli:latest $*"
The existence of Flatpak etc. is a misguided concession from the FOSS community to private businesses and to software developers who are used to packaging for the cloud. The model is not appropriate for desktop or mobile software -- there is a reason that filesystem access is extremely restricted or impossible on mobile platforms, and that even Android has moved to dynamically prompting for permissions when apps use them rather than bundling them into a single prompt at installation.
For Flatpak to work, we need MUCH heavier sandboxing, which will be detriment to productivity for desktop users for certain classes of applications, and may prevent many types of applications from being packageable as Flatpak. I think this is a fine compromise. I'm OK with installing Spotify as a Flatpak (given better security, not now) but keeping my webserver, database, file manager, terminal, programming language, and other "system" software in the OS repository.
And that's what we're talking about, effectively; how self-contained and sandboxed the package itself is.
They just use some combination of rpath fields and virtual filesystems to make sure the dynamic linker only inspects the paths mandated by the application author.
That's what distribution maintainers do.
> They are not trying to be more secure than manually installing packages on your system.
That's downgrade from distribution experience.
[1] https://wiki.archlinux.org/index.php/Nix
[2] https://ariya.io/2020/05/nix-package-manager-on-ubuntu-or-de...
/snark
I get the idea of Flatpak. I want some kind of app sandboxing. Ideally with a good UX and shared libraries, however.
But the apps themselves still show "Sandboxed" when they aren't[1]. It's trivial for the flatpak "store" to just hide "sandboxed" if the flatpak requires access in its manifest. The Microsoft/Windows Store does this. UWP apps are sandboxed and permission-managed, but if a store app requires full access, the permissions section[2] says:
> This app can
> Access all your files, peripheral devices, apps, programs and registry
[1] See first screenshot in OP article.
[2] https://www.microsoft.com/en-us/p/microsoft-flight-simulator...
The GNOME designers are working on a redesign of this area: https://gitlab.gnome.org/Teams/Design/software-mockups/-/blo...
There are other software installers that can install Flatpak apps, e.g. KDE Discover.
So this is a valid criticism of GNOME Software, but not of Flatpak.
Redefining the term and then claiming that what someone else meant by it is not in line with what you meant with it is ... well it is messed up.
They are sandboxed, but rightly Gimp has access to your whole filesystem because that is what people who install it expect.
Of the 30 apps I have installed via flatpak only 6 have access to the whole FS or my entire home directory (Zotero=home, Krita=host, KolorPaint=host, Inkscape=host, Gimp=host, Geeqie=host), and of those 6 only 1 (Zotero) of them seems like it may be fine without it.
Having access to the host FS in no way mean to me that Geeqie is not "sandboxed". It just means that what I would expect is the case. If you want to change it, go open up flatseal and change it.
They can be sandboxed, but that doesn't mean every Flatpak package should be labelled "Sandboxed". Especially if said app isn't actually sandboxed and has full filesystem access.
Who is asking this exactly?
As an arch user and technically a fedora, Gentoo, slackware, Ubuntu, debian user, I'm not asking for this.
I like how I install packages.
Installing garbage from a webpage like some windows pleb or having to eject weird desktop download things after drag and dropping things on a Mac is not something I want.
Please stop pushing this idea about flatpak being better, its not for a lot of users and for me, security doesn't even enter the equation.
But the idea that random flatpak maintainer has better security processes I place than the sec team for many distros is laughable at best.
You can wrangle the argument all you like about ideal world scenarios but the fact of the matter remains that suboptimal ideal still works out as more effective in the real world. Tragedy of the commons problems generally do require sub optimal solutions in the small to solve in the large.
Arch has aur, arch can sideload rpm/Deb's, Mac has home brew, who needs this?
The only people I see using flatpak is the 50 odd Linux users we have at work, they constantly have dramas trying to make things work around home directory sandboxing, permissions, updating and more
> Single way
Why is this valuable? Just saying it doesn't make it true.
Why do we need a single way to install?
I'm not saying it's a bad thing, but giving up home dirs and a bunch of other platform specific benefits is a cost I'm not willing to pay for some made up ideal that gives me a worse experience.
Flatpak sounds like a shitshow, but the not because it doesn't meet your specific requirements.
Are you trolling? I think the answer is obvious: less duplication of efforts may make the linux ecosystem be more lean which may mean more manpower to... bring the year of the linux desktop.
Distro package managers have more than 20 years doing this. If you want to replace them I think there should be fewer drawbacks. Otherwise you are throwing out decades of design, thought, bug fixes for something more problematic.
If the packaging is done by the dev you are assuming that 1% extra effort wont be spent playing chess instead of adding features.
If the packaging is down by an interested party for that distro you are assuming that a person competent to write a package file is even competent to say write an app let alone interested in doing so.
I agree there are a lot of distros to package for, but I'd say the bonus of not having to maintain and update all the dependencies outweighs that fact.
For example, there are a lot of tools that can generate Debian packages for you if you don't want to spend any time learning the manifests. I assume these exist for most distros.
Smart distros keep things close to upstream so the burden is small.
This is a weird argument.
Now you want each developer to manage dependency updates for their application? I don't trust them to develop their own app let alone apply security patches properly.
I put my software in my webpage and whoever wants to download it and use it does it. If they don't trust it well then I'm sorry.
https://docs.flatpak.org/en/latest/hosting-a-repository.html
That doesn't mean I enjoy compiling some incarnation of webkit every few weeks for multiple hours on a laptop, in particular if it's just for a single application (in this case: Nextcloud client). Same for 32bit stuff, I have absolutely zero use for these libraries outside of closed-source games, so I'd rather have them just work than full control over them.
> like some windows pleb
I'm not sure if you're serious or making fun of stereotypes and thus don't know how to respond.
The other side is that Software Developer Foo isn't necessarily going to have the resources/inclination to work with your distro maintainer. You may decide to avoid Foo's software as a result, and that's totally fine—but if I like Foo's software and want to use it, Flatpak gives me that opportunity.
Staying silent is as good as encouraging the echo chamber outright.
People are pushing this shit because it's trendy not because it's good.
But basically, as with anything open source, if you don't like it, don't use it, make some other choices, or build your own. I see a lot of people whining and stamping their feet here but not a lot people building alternatives. Quit whining & start coding if it matters that much to you. As far as I can see there's Flatpack, Snap, and not much else here because nobody can be bothered apparently.
I don't trust developers to designate things as stable.
Now is flatpak secure for installing closed source app? At least not when they have full x11 access when using x11 desktop.
I as an user could at least expect a sandbox that protects a rogue application from modifying or even reading critical files without user consent: .config of other applications, .ssh/, shell configs (profile, rc). A web browser may require create-write access to ~/Downloads but not arbitrary read or write access anywhere else with the exception of save-as/upload explicitly requested by the user*, and that could be done by the OS file selection dialog giving back the filename + a token. And so on.
Perhaps it could even be abstracted to a common "profile" for application classes, and go even further than that and have stuff like raw USB/Bluetooth not authorized by the browser but by the OS/sandbox layer (to prevent attackers exploiting a browser bug).
Not so much in a system that links executable dynamically to system provided libraries (e.g. Debian), or provides system wide maintenance updates to statically linked binaries when their dependencies receive important updates (e.g. Alpine).
...which really covers every sane, actively maintained *nix system with a package manager, so in that sense Flatpak is definitely a step down. Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks.
The only advantage I can see for them is in providing closed source software, which OS maintainers simply can't maintain and update. A developer advantage may be that the standard of inclusion is much lower than for Debian or OpenBSD, but that's IMO a user disadvantage.
Well, yes, and it's the most obvious approach. You're trusting the person producing the product for producing a good product.
The distro approach is great, but it doesn't scale well for obvious reasons and it makes software development harder due to downstream issues often going reported as upstream issues.
I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.
That's a generalization. Specifically, I'm trusting the person producing the product to do something that e.g. Debian has a proven track record of doing quite well: maintaining dependencies so that I have a secure (and consistent) system altogether...so well that I'd rather trust them to do it over any existing flatpak vendor, and definitely more than trusting n vendors for the n flatpaks I have installed.
> The distro approach is great, but it doesn't scale well for obvious reasons
Regarding what aspect doesn't it achieve the scale necessary? It's not obvious to me what you mean at all.
> and it makes software development harder due to downstream issues often going reported as upstream issues.
A cost of system-scale software maintenance, for sure.
> I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.
I don't fundamentally disagree. My point is that I think it's a security risk to leave it to every developer to maintain their dependencies as they see fit, and that this is a problem that flatpaks create that a well maintained distro software repo doesn't have. It's better to acknowledge this risk and consider it to grow as you install more flatpaks than to ignore it, expecting that every flatpak vendor will respond in a timely manner to dependency CVEs; the trust I place in Debian—by necessity very high—now has to be multiplied for each individual flatpak.
they should have leveraged the package model that linux distributions already have and viewed them as mix and matchable layers much like packages are mix and matchable. with full dependency resolution. i.e. creating an "apache" container image should be as easy as "apt-get install apache" but without actually installing anything. just creating a manifest that references the packages/layers that are needed.
simple upgrades a container image is then just upgrading the set of layers in the container image, and unlike docker where even if 2 layers are exactly the same content, if a layer "above" them is different, they are different layers, in a package -> layer concept that's unnecessary.
In fact, this is what I published and created the notion of container images that are defined by a file system that is created by composing a set of shared layers together, but Docker took the easy way out and punted on that.
this would also make it simple(r) to do security analysis on container images as well as compose multiple images together.
https://www.usenix.org/legacy/events/atc10/tech/tech.html#Po...
https://www.usenix.org/legacy/events/lisa11/tech/#Potter
(which also goes to my in joke that I'm the only one who can get a job that requires 10+ years of docker experience ;) )
I for example use conan(.io) for some binaries - and there you can compose arbitrary packages - and theoretically it can serve as the basis for a package based approach to composition.
Sometimes before getting the capacity, one should learn from what already was achieved in the past.
But, debian packages aren't really made for this directly, as they have their pre/post install/remove scripts. My "hack" was to treat every package as an dpkg --unpack version (i.e. not configured) and then at image "build" time (i.e. each image is really a layer that is a manifest of dependent layers + data created at image build time), we would dpkg --configure --pending all the composed layers (with a bit of magic happening behind the scenes to make dpkg realize that the packages were unpacked but not configured yet).
This mostly worked well, but you could have some ordering issues. A bigger issue is because debian doesn't expect this to happen, it creates encryption at install time (say for ssh), not at first run time. So for example, if one created an ssh daemon image, any instance run from it would have the same key. not a great idea. Of course, its possible to engineer my way out of this (simple case would be to write tooling to recognize these cases and inject it into the created images), but it goes to why a direct conversion from debian packges into layer wasn't a silver bullet solution. I had the thought that perhaps an Ubuntu type approach would work, where some packages are wholesale imported from Debian into Unbutu without any changes but "important" packages ae modified to fit Ubuntu better could work.
As an aside, the 2 papers referenced above were my "job talk" for my post doc at IBM Research, and got me the job. I tried to get support to continue this line of work there, but that never happened (and then my manager left, and I was left working on unrelated cloud stuff for the last 1.5 years there). Of course, this is now important to IBM (see Red Hat purchase).
I wasn't approaching this from the pet/cattle metaphor, so I also gave my system the ability to upgrade instances in place by mark removeding layers as unlinked (i.e. ignored by readdir/lookup), and adding new layers. A big advantage here over traditional package management is that this made upgrades "atomic". For example, when you upgrade libc in the traditional package managed world, your system is temporarily "broken", in the sense that any executable that tries to run in between old libc removal and new libc installation will fail as its not on the file system. However, in the cattle world of containers, this is probably unnecessary complexity.
I personally like appimage, but I don't mind using flatpack because it is so similar to Docker and is also supported on most major distros. Distro repositories aren't going anywhere, and I think flatpack strikes the right balance for users and developers.
simple examples:
1) we spend time ordering the layers we install in docker so as not to waste space if an earlier layer changes. in layer aware building, this isn't an issue.
2) if one does a run apt-get install XYZ, unless one nukes one's cache on every build (possibly ruining all efforts to not waste space if data comes out somewhat differently), one will not actually be getting the latest packages.
The primary benefit of leveraging an existing distribution is that you have all the software they have already built (and is built to work on them). Which I don't want to downplay the value of that. I understand why the decisions were made to leverage them, I just feel they come with a cost.
I'd also note that the prototype I described was basically finished being built 4 years prior to docker. we've learned a lot since then, but I think we've also forgotten a bit.
If one really wants to simplify it, I'd say "Debian's package model" as that's what I have the most direct experience with.
1. Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox.
2. Common runtimes have un patched security issues.
Re 1) This is a backwards compatibility option until app developers start explicitly coding for flatpak compatibility. Given the money involved (~0) I can understand why it's taking some time. As a user one can address this with flatseal[1].
RE 2) This is more a problem of the ecosystem rather than a problem of the people developing flatpak. And it's not like this problem is not often encountered in other ecosystems. This just shows that the ecosystem is still in early stages. Still it s something worth pointing out and hopefully people at freedesktop.org look into it.
[1]: https://flathub.org/apps/details/com.github.tchx84.Flatseal
The main issue seems to be the fact that flatpak still claims these apps to be "sandboxed", which is simply a lie. Properly communicating this situation to the user is all the article really asks for (and this seems very reasonable)
All of the above however need resources (ie money) and that's why things are moving forward so slowly.
This is an area where Ubuntu's snap ecosystem does better. Instead of essentially trying to create a meta-distribution, snaps provide a way to run software built for Ubuntu LTS on other distros, at least in theory. They are compiled against Ubuntu LTS runtimes and are built primarily from packages in the Ubuntu LTS repositories. Further, when any Ubuntu based dependencies of snap packages get security updates in the Ubuntu repositories, the owners of said packages are prompted to rebuild their snaps.
In contrast, it's not clear who is assuming responsibility for maintaining flatpak runtimes like org.gnome.Platform, or what is their support lifecycle. It would be better to promote runtimes based on a well-known distribution's packages, since they would get security updates in accordance with that distribution's security policy. For instance, something like https://developers.redhat.com/blog/2020/08/12/introducing-th... looks more promising from a security point of view.
Now, flathub does maintain a collection of "modules" -- basically prewritten manifests for building various common dependencies from source. But that collection is still quite small, and writing a working flatpak manifest can involve duplicating a lot of the hard work of Debian and Ubuntu package maintainers.
Recently, Fedora started something promising from a maintainer's point of view by:
* creating a flatpak runtime based on fedora releases, and
* allowing one to specify existing Fedora packages as dependencies instead of having to figure how how to build all the dependencies from source (https://docs.fedoraproject.org/en-US/flatpak/tutorial/).
But it is still in its early stages.
This is why the idea of "runtimes" is bad at the core: existing applications do not benefit from new features and fixes in the latest version of the runtime. But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares (and they want to break X11 too instead of fixing it because "it is too hard to fix it so let's throw everything away and make something new that for some magical reason wont also become hard to fix in the future").
Why the idea of having a standard set of libraries to handle common GUI tasks that are available "everywhere" (in desktop distros at least), just like the C library and X11 library (so far) is available everywhere and can be relied on in the long term (think decades, not weeks) is something that sounds like science fiction instead of common sense is beyond me.
And TBH i'm not sure if a C++ library can ever be backwards compatible, at least without major major hacks (think like automatically generating a "proxy" library that uses the old ABI to forward calls to the new ABI - i think the only C++ API that ever did something like that is Haiku so that they support both G++ 2.95 from BeOS and modern G++ programs from the same libraries - even then this is easier for them since they're the OS and can decide they'll always distribute those proxy libraries, which isn't something you can rely all Linux distros to do), since C++ does not even pretend to have a stable ABI. I know that the G++ developers are trying to keep things compatible but i'm not sure of the C++ designers care that much.
On the other hand on Windows, just a few hours ago i was playing a recent(ish) game made with RPG Maker 2000, which as the name implies was made two decades ago and yet still works perfectly fine. And i have a bunch of older programs that work fine linking against the latest version of Windows 10's libraries, with all the fixes and new features they've got over the years.
The Itanium C++ ABI is the stable ABI on Linux, and the C++ standards committee (along with those who maintain the Itanium ABI) cares very much about not breaking the ABI. For example, the C++ committee is not able to make any ABI-breaking changes to the standard library, even where it would be advisable.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...
I remember this having happened multiple times before, though thankfully it has gotten less common over time.
The C ABI is stable, except when it isn't (largefile was a fun one...)
this is really well put. I wish people realized that if they are doing essentially the same thing folks prior did, they really will end up with the same level of results. Unless they really have identified a magical fix to entropy.
Admittedly, it takes people aware of the issues with the current stack, and the ability to take a different successful approach.
Those behind Wayland were competent about X11, as far as I know. But for some reasons, adoption of Wayland is still scarce.
Actually, I'd say hardly anyone above the kernel in Desktop Linux cares. Which is indeed among Desktop Linux's largest issues that will likely never be solved because its culture is unable to even comprehend the problem.
Also personally some years ago i tried to build a small GUI library i was working on at the time under a Red Hat distribution from 1997 and then run it on my 2017 Debian[0] (the colors are off because i didn't bother supporting colormaps) and it worked perfectly fine, showing that X11 (which is the only mandatory requirement the library has, under Linux at least) and of course the C library (the binaries are linked dynamically, not statically) do have two decades of backwards binary compatibility.
It is just everything else that is built on top of that that doesn't work. At least everything else that modern desktops use, AFAIK something like Motif is also binary compatible going back decades (which is how Lesstif worked anyway since it was supposed to be binary compatible with Motif).
In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.
.deb packages format for example are quite uniformly established and provide a lot of interfunctionality on many different systems. Of course you are going to find other obscure systems and even big other ecosystems (RedHat obviously, and derivatives), but the format we are looking for doesn't have to be the single one either. It just has to work well enough and be somewhat universal. .Deb-level of universality would suffice just fine.
Same for desktops, again there are two: gtk-whatever and qt-whatever. All software works on both of them, so again I don't care.
Same for installing software. Installing Wolfram Mathematica is literally downloading one file, clicking on it and pressing Enter a few times.
If anything iOS and its appstore showed that the repo model is great and there is a reason why microsoft developed/copied "winget".
For instance, gtk and qt are not desktops. They're ui toolkits. Bunches of widgets that can be composed to cobble together a UI.
That's completely separate from the topic under discussion, which is mode of application delivery. FlatPak involves using namespacing and containers to "spin up" a virtual system with only visibility into those slices of the overall host needed to run the program.
This is good because it at least keeps unfamiliar software constrained somewhere predictable, but poor because often it won't use OS host libraries, which are generally kept the most up to date, and worst of all, enforces a complexity and debuggability tax where one has to have an intimate understanding of what is going on "in the box" if something goes wrong.
Other ways mentioned are the distro model, whereby distributions maintain repository ecosystems and make decisions with regard to FHS compliance, system tooling, update pipeline, etc..., and use those to support their user base.
There is the original "compile and stage it yourself" crowd, who basically concentrate on reproducible build capabilities, but tend to lack in automatic dependency resolution.
There's the Mac way, which isn't terrible. It tracks and designates places for libraries, Frameworks, and Applications, and has a lot of automated and well integrated ui-tooling which makes the user experience of software install easy, but it's just another paradigm you have to track when trying to write portable software.
There's static linking, which delivers executables that are entirely self-contained, but tend to be bigger memory footprint-wise, each have an upgrade path separate from every other executable, and benefit not at all from dynamic linked libraries on the host system.
Then finally, there is dynamically linked executables. They're small, commonly reused code is loaded once in memory you have the additional complexity of the linker to be aware of, but you can update the entire system's audience of a particular library at the same time... Which can be a double-edged sword given how the maintainer scripts the install or sets up their system/build environment.
Personally, I just sidestep the issue myself by digging into and learning about software I use on a regular basis with disassembly tools, and treat all of my systems the way a good farmer treats their livestock. Distant reverence, but with a careful eye as to whether there is something wrong, and a hard fought for willingness to kill something and start from scratch. It's the only way I've found to be truly safe and resilient in an environment where everyone optimizes for their own particular definition of convenience.
(My definition of convenience is a minimum difficulty in troubleshooting what might be wrong, so I favor fewer abstractions as that entails less Tower of Babel to wade through).
Full disclosure: my approach generally would classify me as a bit of a curmudgeon in the industry as I still approach computers as being analogs of physical machines. There is a healthy corpus that revels in abstraction, but I'm not really one of them. I like to have a ballpark understanding of what the artfully arranged beach sand is doing. Adding more abstractions or having the computer do things itself is generally not something I strive toward as it almost always comes with an unacceptable increase in the overall complexity inherent to navigating the Gulf between how I and everyone else thinks the system works and how it actually does.
More than anything else, in my experience, keeping that Gulf small leads to better overall satisfaction from a lay User. YMMV.
And I never claimed that. Again, as a user the difference between gnome, cinnamon or unity is not all that interesting, so I simply wrote "gtk-whatever" as an umbrella term and "qt-whatever" for kde plasma and lxqt.
My basic question is the following:
- If I find software that is only available as a snap, I will use snap. It works on any distro.
-If I find it only available as a flatpak, I will use that. It works on any distro.
- If I find only an app image, I will use that. It works on any distro.
- I get an installer from some big commercial software. It unpacks itself in /opt or uses a docker image or... . Again works anywhere.
Why should I, as a user, care which distribution mechanism you chose if they all work anyways? Why is "fragmentation" an issue, if whichever you choose works everywhere regardless?
Want to run your program, but I only support something for hardware that supports full client virtualization, which your system doesn't have? Oh well.
Oh, you wanted to run that Snap, but the cache is invalidated or cleaned, and no internet connection? Oh well. Sucks to be you.
Oh crap, you need to do that one final fix real quick in that one program, but oops! I just force pushed out a functionality breaking security update! Sorry bout it!
It may not seem so important from the casual user perspective, because you may not sample different configurations or distribution channels as devs/maintainers/admins, but you'll hit it one day, and you'll be as pissy as we are. Why doesn't this shit just work?
And the answer is, because it isn't magic, and it has to get to you somehow. Again, I hedge on the side of being deliverable with the simplest set of abstractions possible, and I'm old enough to remember when complex things actually came with manuals; so I prefer that delivery and understanding the ins and outs of the tool. You don't get that with FlatPak or Snap without cracking open the container which is far beyond most average computer users, and I place value on people being able to easily learn how to program, utilize, or reason about computers better, something that no container will ever teach you; especially given that in order to understand them you need to already be pretty deeply immersed in the mechanics of computing.
On the other hand, a zipped workspace with some tooling, READMEs and documentation can make for hours of discovery and familiarization with system fundamentals.
It's an approachability thing, and we've totally lost touch with it as a modern industry in my opinion.
I mostly stopped using other operating systems a long time ago, so my impressions of them are partially ouit of date, but for my previous job I had to use a Mac for development, and lately I'm experimenting with Windows in some virtual machines in order to automate the setup of certain tools for Windows developers. In neither case have I seen some desktop environment feature and thought ‘Wow, I wish I had something like that on Linux!’.
Same way you don't expect cohesiveness between macOS and Windows, I think it is bit unreasonable to expect cohesiveness between RHEL and Ubuntu or whatever.
That's the problem.
The desktop distros could and should have done a lot better to coordinate on fundamentals of user experience in the age of the open/hostile Internet and frequently updated software.
Unfortunately the website isn't loading for me. Wikipedia shows their projects seem to be focused on lower level graphics/UI issues, but not app packaging and security issues that have become very important in past 10 years.
https://blogs.gnome.org/alexl/2015/06/24/xdg-app-moving-to-f...
> Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking.
Are these features lacking? I mean I can open flatseal and go disable Geeqie access to network and filesystem, so not sure how it is lacking - maybe I'm missing something.
Of course if I disable Geeqie access to the host FS it kind of defeats the purpose of the app, but at least I guess you can technically say it failed in that for Geeqie to operate as I expect it to, it needs access to the host fs.
EDIT: Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access.
Where the heck do you keep your stuff if not on your fs?
If you want to go fiddle with the specific directories that option is available to you in flatseal.
And I just had a look at some other apps like Bitwarden, Teams and Spotify, and there the permissions is much more constrained, for example none of those have blanket access to the host fs or home directory. Spotify for example is limited to xdg-music and xdg-pictures.
Another EDIT:
flatpak also does support blacklisting of directories, see nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference...
I think support for this is lacking in flatseal currently but I'm sure it is coming.
I mean they are lacking if we don't use Flatpack or an alternative so we have to either use it or invent something better.
> Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access.
I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Hopefully flatseal can do this.
Well, as I said I see them in flatseal so either flatseal is misleading or the features are there, and I have no reason to think flatseal is trying to deceive me so I assume they are there.
> I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading).
Fire up flatseal and change the permissions to what you want it. I'm sure you can also petition for xdg-code directory or something and then keep all your code there and request the packages be changed to default only work under there but I suspect most people would not be so happy with this.
I am not sure how you expect the package maintainers to know where exactly on your FS you keep your code, I also don't keep mine in my home directory.
And maybe a blacklist would make sense, but if all that is needed is a blacklist then I would harldy say that flatpak failed because it is not really that difficult to fix that deficiency.
EDIT: Actually blacklisting is supported, see --nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference...
So really everything is there, maybe everything is not available in a nice neat UI, maybe the UX is not what it should be, but the core underlying system is not "lacking" these capabilities AFAICT.
What's wrong with firejail?
More and more, I view flatpak-style sandboxing as something kind of like wine. It's very important that it exists, as a stop-gap measure to allow people to run the programs they currently depend on. With wine, that's Windows-only programs; for flatpack it's proprietary applications, while retaining some control over their permissions. But it's not an ideal long-term solution.
Using wine in the ideal way requires creating gigabytes of duplicate files (since you want to run one program per prefix, since they may require different and incompatible tweaks). Both it and flatpak make it harder to write shell scripts and generally to hack on your operating system. More importantly, both solve problems that, while they aren't going away any time soon, could be solved just by using high-quality, trustworthy software that targets GNU/Linux natively, without the downsides of these technological solutions.
So, while I do use both of these technologies and appreciate them very much, I prefer native packages and would rather put my effort toward better supporting people who want to write software that is distributed that way.
This is how you run a third party Firefox binary package downloaded from Mozilla:
tar xJf firefox-x.tar.bz2 ; cd firefox ; ./firefox
Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications).
It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.
Most 3rd party applications are actually an installer script that places the contents into /opt/_APP_NAME/ or where ever the end-user requests they be placed.
The closest I'm come to mimicking Mac style on Windows to create an installer that does not actual install but extracts the contents to user's temp directory and executes the application. Needed a simple solution so the end-user just had to download and double click to run the application since they might not have admin rights to install the application.
I actually prefer the MacOS style since installing and backing up applications or moving to a new computer is the same process.
I create these self-extracting packages all the time too. Getting the icons and such right on the package can be a bit of a pain so I made a quick script[0] to automate the process. You may find it useful too.
If you're unfamiliar with computers then you should only use things sandboxed as heavily as web pages or native apps that have been carefully reviewed by operating system maintainers.
If you know enough to make a useful decision on the safety of an app than you can probably build it yourself from github.
This practice of flinging binaries around is only useful for "software markets" and almost always seems to end up distributing the most pathological garbage possible.
Distributing binaries will absolutely bring about calls to lock computing down to 3rd party distributors because the kind of people that can't handle typing `./configure` are the same kind that will pull random maleware off of google.
No good can come from installing closed software anyway.
Yeah, it is so easy that no one ever uses containers to ensure a consistent and working build environment for software!
Oh wait, yes they do.
There are decades of very good desktop applications that are simple and easy to build. Flatpack will just encourage things like slack.
1) They don't need to be put in a special directory to work.
2) AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).
I know but AFIK that's the way that's meant to be done.
> AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).
Why don't we give FlatPack and Snap up to just use AppImage then? Chances are AppImage also has some cons and is inferior to Flat pack in at least some ways.
flatpaks provide apps that weren't packaged before. They provide easy an easy way to install apps that are bleeding edge and may have used newer versions of system libraries.
Source: working on a open source snap applications (without the personal-file interface despite being able to install packages into the sandboxed $SNAP_USER_DATA directory): https://github.com/argosopentech/argos-translate
[0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal
However, what I'm missing in most comments here is that - if I'm not mistaken - Flatpak and most others are essentially tailored towards distributing binaries, which is at least my personal gripe with them.
The reason is that especially with Nix I'm used to ad-hoc `.override`/`.overrideAttrs` and patch software in ways I'd like them to behave rather than being degraded to being the sole user of a software not supposed to be modified.
Flatpak, Snap and even Docker go the opposite route, which essentially degrades FOSS to essentially proprietary software, if even upstream would just point you towards "just use the Flatpak"™.
Others here also have suggested that it would be a good way to only distribute proprietary software, but as a Nix user who's packaging and patching (well, and reverse engineering) proprietary software I'd even disagree on that, because patching the environment and the entire dependency graph is something very useful which you'll lose with Flatpak/Snap.
Usually installing a large package from a .deb file takes just a few seconds. It took a few minutes to install chromium from a snap. It's faster to install programs on Windows.
What's up people?
Not everything flatpak does is worse than the status quo. Whether it's worse all things considered is debatable.
For instance, once you have two places a software package has come from you've added the cognitive load in debugging to determine where a given package came from.
> [...] unless there are LARGE advantages to having the second one.
That's the thing: What's considered a "LARGE advantage" is highly subjective. Not something you can really quantify.
Fonts and theming are an issue, I agree, however, this isn't entirely the fault of the flatpak maintainers but in part the fault of a fragmented and hard-to-compose linux ecosystem when it comes to their configuration.
The IME issue is a problem but I don't think a dynamically linked system would benefit much here. The solution is to make portals between flatpak and the system more extensible and versioned, so that an outside daemon an talk to flatpak apps and potentially flatpak could even try to determine which runtime to use based on what outside portal versions are available.
Beyond this, and not unlike systemd, flatpak has been pushed hard down people's throat by powerful entities within the ecosystem, so it's not surprising that in both cases there has been some intense backlash. I also personally think that in both cases it's warranted.
I get the author's concern but there is nothing useful in this article. It's misleading suggesting that the problem is with flatpak when the problem is that certain applications aren't using its full capabilities, aren't configured correctly and are in need patching. Or in the worst case, might need a redesign to fit the sandboxing model. This needs to happen with any sandbox that uses this model, not just flatpak. There is nothing else that can be done about this short of suggesting users switch to a different sandboxing model like Qubes. (Maybe the blog author can try that too and see how it goes, or could develop their own sandboxing model just to see how hard it is on a complex system like Linux)
So, GNOME Software has included a "Permissions" field (which lists an application's specific sandbox holes) since - if I recall correctly - GNOME 3.34: https://i.imgur.com/lCGgA1B.png. Not perfect, but definitely better than pictured. It's a bit of a shame that people have to use older versions of GNOME in 2020, but then, it's nice that Flatpak makes it easy to run new applications regardless :)
Also, I was trying to verify the author's claim about a vulnerable libssh in the gitg package, partly because I was curious whether they'd bothered to report any of these issues upstream. Looks like that was fixed in May: https://github.com/flathub/org.gnome.gitg/pull/12. Similar story with ffmpeg: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/....
So, woefully behind schedule, but, how long was the author sitting on these? It would be more accurate, less irritating, and more persuasive if they simply talked about it after the fact: this happened, various things are wrong with it, it should be avoidable, etc.
Sounds like a tinfoil hat theory to me. Powerful entities? Pushed down people's throat? You are free to ignore Flatpak, no one is forcing it on anyone.
Its hard to have a civil discussion if everyone pulls into a direction you deem wrong and your words are never convincing anyone.
I have similar resentments when people in my company push for docker on embedded systems, because they are used to docker on the server, and whenever I ask them which problem they are solving on the embedded system with docker, they describe things that are wrong.
I don't share the authors strength of opinion on flatpak, although I see the same issues, and I don't want to advertise or excuse strong "tone" - but I understand the frustration.
Aaargh!
A particularly odd one as most embedded systems are handled as "images" of some sort - firmware blobs, ramdiscs, imaged HDDs for embedded PCs and so on.
I'd much rather deal with Dockerfiles than buildbake.
I think nix actually represents the next useful stop here: it avoids just piling another layer of abstraction/virtualisation on the pile and actually reinvents the package manager in a way which actually solves the problems docker exists to solve but in a more complete manner. Bitbake I think actually represents a much messier implementation of the same ideas: just like nix uses a functional language to express package configuration, so too have bitbake files grown the same kind of functionality. The main things which bring bitbake down are the language is ridiculously quirky, hard to debug, poorly documented, and has any number of soundness holes (as well as a good amount of action-at-a-distance akin to INTERCAL's COMEFROM statement which is simultaneously really useful and really frustrating)
Is this something that yocto itself helps with or just something accomplished by a thousand people hacking at .bb scripts? Last I checked features like the sstate cache came with big caveats.
Dockerfile layer caching seems much more effective at shrinking build times.
It reminds me of a talk by Jonathan Blow - "Preventing the Collapse of Civilization" - https://www.youtube.com/watch?v=ZSRHeXYDLko. He makes the point that Docker is a solution to what was a non-problem.
This code-piling approach seems destined for failure.
This is a real problem an regular that regular Linux distros are not very good at.
The boundary between a binary tarball and the rest of the system is very poorly defined.
Which, as noted, are problems that didn't used to exist and were created.
"How much functionality is added to Facebook year after year? It's not that much!"
This is in support of his argument that per programmer productivity is approaching zero, due to the over-use of abstractions.
Facebook is and has been hiring top talent software people for years, and in large numbers, but most of them aren't working on https://facebook.com/ or https://instagram.com/, at least in any visible way.
I've been programming on a nearly daily basis for over 40 years now, and my total productivity has never been higher. Not primarily because I'm smarter and more experienced, but because the tools available to me are just awesome.
I can write a functional app that allows a hand full of the billions of people around the world to interact, and I can do that in less than an hour, and on the cheap, perhaps even free.
40 years ago, that would have required a lot of time, up front money and ongoing maintenance costs.
There are countless examples.
I'm not dismissing the hazards of abstractions and the freakish amount of complexity that we face today. And I agree that a lot of it is done wrong.
It really has not, flatpak is not madness. It has issues, they are finite, they can be fixed, they should be fixed, but it is not madness. It is better than AppImage or just running random binaries you find or compiling it yourself.
Also, flatpak doesn't only compete with "AppImage or just running random binaries you find or compiling it yourself". It competes with the package manager, that has worked well for decades. The package manager has issues as well.
Maybe from the authors perspective it looks like everyone wants to throw away the package managers because of some issue they have, instead of tackling these issues. If he then points out the flaws in flatpak, people say "sure it has some issue we need to fix".
Actually, why are people so concerned about tone nowadays? It matters, but this is perfectly fine.
I feel like you can't find anything to nitpick about the post, so you pick on the tone instead.
In case those aren't enough; I think the issues brought up aren't issues with flatpak.
The first issue is with a GUI application on top of flatpak and the second is a packaging issue of the runtimes.
These aren't inherently problems with flatpak so I mentally don't count them.
https://i.imgur.com/VMsj6mk.png
Is it a bad interface? Sure. Is the list of permissions hard to find? Hell yes. Is the Sandboxed emblem kind of misleading? Yeah. But here (in at least GNOME Software 3.36) you see a list of the relevant permissions available to the application. Nobody is lying here.
For contrast, here is an application with a stricter sandbox:
https://i.imgur.com/lCGgA1B.png
The point here is both of these are sandboxed. Each sandbox just has particular holes in it. For GNU Octave, more than seems appropriate. Users misunderstand that in the same way people misunderstand "autopilot" and that's a good issue to bring up, but then I don't think non-technical users understand what "sandboxed" means anyway and technical users should be able to take one more gorramn step and learn that "sandboxed" obviously comes with particular limitations [at least in the present day] or it isn't going to do anything.
Flatpak has a lot of claims [1], author feels them as a lie. And he provides facts in support. Linux "next generation technology" would certainly alert users of insecure application. This does not. The story of themes and dbus shows how hard it is to contain all dependencies.
Also there were a lot of claims here that Linux distributions makes no good, static linking is better and libraries would be patched.
Now lets switch perspective. Windows users are perfectly fine running closed source software which may contain outdated dependencies. Most of them are not updated anyway. And it has gallery, something Winget still lacks. Looks like next gen. What is cry for open source developer may be fine for consumer.
Personally I'm fine with Flatpak, Appimage. There should be some way to install proprietary software. And some starting point to make it safe.
It's fine if it's a trade off between usability and security but then they shouldn't call it sandboxing or make it very clear that that's the trade off.
Though the trusted filepicker is tricky to do when one logical document consists of multiple files. For example separate subtitle files next to a video file are common.
Certainly one could select all the files and drop them in. But that's asking a lot of the opening program, and isn't usually how they're set up.
For multiple files per document, the solution would be either multi-file select (bad) or allowing apps to specify very simple rules for additional files, ie "removing extension, also mount all files starting with that name".
The filepicker could integrate that and either show all those files as a single document or select all files for a document visible, so the user is informed.
..à la Qubes.. https://www.qubes-os.org/doc/copying-files/
I think the Downloads, Documents and Movies folders people tend to have etc. those major sub-folders would be enough for normal use.
Also, perhaps file type limits could be imposed that mean at that files are only accessible to apps that can open them. Of course, I'd want my text editor to be able to open files across root file system, if I open it as root - so I can see how quickly a person can want sandboxing, and then also want none - but the less apps with privileged access, the better.
Also I think some people had hopes it would be closer to IOS level sandboxing, which is heavily restricted on file access, and frankly can be annoying because of it, but does have the security benefit at least.
Also, the security update gripe is significant. The isolation of packages only matters if it works. Like at least if I run stuff myself inside container, I can choose to update the underlying OS and force certain packages etc. at the same time as sandboxing, and mount only certain folders if I actually need them.
I think it's hard to make it both simple for users and powerful enough provide the levels of granular access I'd expect for context specific sandboxing. I would want a principle of least required privilege, with some ability to escalate it (like Android asks me all the time if I want to allow software to do stuff at point of the privilege being required).
I had high hopes for Flatpack, Elementary OS went all in on it for a better way to deliver their curated apps. https://blog.elementary.io/elementary-appcenter-flatpak/
I guess though, they curate and approve the apps, so perhaps they are able to make certain assurances that are not universal to Flatpak availability.
The texteditor gets no FS access. Instead the call the portal to request the user to pick a folder (for projects) or file with a specific ending (the compatible file formats or if folders can be picked can be defined statically for most apps).
If the app was started with root privileges, it gets no root privs but the portal transparently translates it's IO calls to the actual file.
But only that file. So even if the text editor had a CVE, it couldn't overwrite arbitrary files, still needs permission from the user by showing them a file picker dialog.
And you could still ban certain directories, so even if you started as root, the text editor cannot access /etc/sudoers and /etc/passwd, for example.
That's SELinux, if configured well. Files are labeled according to their function and access to these files is whitelisted according to the security label of a process. For example, no security labelled process can access my private ssh keys, that's guaranteed.
It's just a shame that SELinux has such a documentation and UX issue, so almost no one uses it and almost no one uses it well - except for package maintainers and some application developers.
Can someone tell me again what problems do this actually solve? Note: not being Mac-like is not an actual problem.
It also makes it easier to clean up when uninstalling and makes for better damage control by limiting what can be broken if done right, but like the article said this is not what it's actually all about since noone seems to care about these points.
I think pretty much every package manager tracks what was installed manually and what was installed as a dependency of something else, so that it's easier to just remove everything that is no longer needed.
When you remove that package, you now also have to change the configuration of your repos to remove the one that it came from, or arrange a vendor change (the best case, with a powerful package manager like zypper), then run an upgrade to get the default one back into place.
What the GP is talking about is how containerized packages eliminate that step during uninstallation.
If a program depends on a specific version of a library that's not provided by the distro (because it's obsolete, vulnerable, too specific etc), it still can be installed by the package manager, if the vendor provides a suitable version within the package. The nice way of doing this is to avoid colliding with the system-provided package either by using a different name or by installing it under a different path. Many vendors do precisely this when offering their packages.
In both cases, it's easy to uninstall the no-longer used dependency - on the first case, it'll be marked as automatically installed and can be removed with a cleanup command. On the second case, uninstalling the package should also remove the library.
There are some more traditional (in the sense that libraries are always shared by default and no containerization is required for packages to work right) package managers that extend the kind of isolation you describe (‘installing [special or patched versions of dependencies] under a different path’) to all packages, namely Nix and Guix. These package managers also make it easy to do things like take a package definition from somewhere else and rebuild it with just one or two dependencies modified without redefining the whole package, or alternatively take such a package definition (perhaps originally targeted to a different release version of your distro) and rebuild it with all dependencies instead being provided from your current distro. At the same time, since the dependency chains of packages are isolated by default in these systems, it's relatively easy, in case of a special need, to take any package and bundle it and its dependencies into a container for distribution on ‘foreign’ systems. (And for packager convenience, the package collections in these distros may also explicitly include multiple versions of a library in their default package sets in the same way that other distros do, as you describe).
Nix and Guix have their own difficulties and quirks, of course! But one of the things I like about their approach is that their innovation is conservative in a certain sense: it offers more isolation for packages (along with the cross-distro compatibility and potential for bundling that come with that) but preserves the virtues that have been the strength of package management on Linux forever. I would like for whatever really is the future of package management on Linux to share in that.
So I don't think containers are The Way Forward™, although I do think that desktop containers like Flatpak are potentially useful as (1) a step toward more fine-grained permissions for desktop apps in terms of access to files, multimedia devices, and so on; and (2) a way of providing cross-distro packages for applications that (a) have yet to accrue much developer interest from packagers and distro maintainers or (b) are (unfortunately) proprietary.
(Personally, if I really want a piece of software, it's not in the distro I'm currently using, and it doesn't seem especially difficult to package, I will just go ahead and make a package for the distro I'm using. Case (2a) provides a convenient, more managed way for me to evaluate a new program I've heard about without having to package it just to see if I like it.)
Problem: You want to use FooApp 2.0, but your distribution only ships FooApp 1.0. Or even worse your distribution doesn't ship it at all.
In the worst case scenario, you'll learn why the distro is not offering the newest version.
* Try Nix on your distribution [1], package may be already there [2]
* Create package for your distribution, become maintainer, that's not the last time you need it
* Switch to less outdated channel, other packages would be fresh too
* Change distribution
Flatpak has its niche but your use case looks like fixing broken distribution. There is no package, package is outdated, it is hard to make package, it is hard to publish package - these problems already solved.
Hard problems may be
* I want several versions of the package
* I want entire environment like it was 6 years ago so I can run / compile application (in parallel with current)
* I want to run application in sandbox - no network, no file access, no mic etc
* I want proprietary application and they don't play well with Linux ecosystem
Hope Flatpak will address them while keeping security in check.
---
Debian Sid is claimed to be not more unstable than Arch [3]. And I had less problems in a decade than a single Ubuntu dist upgrade. Rolling release does not accumulate breaking changes. Run update once a week and you'll be fine.
[1] https://nixos.org/download.html
[2] https://search.nixos.org/packages
[3] https://linuxconfig.org/how-to-run-debian-sid-relatively-saf...
Snap/Flatpak are just an unnecessary disaster IMO.
The containerization still has advantages. For one you have a solid and predictable baseline system regardless of what distro the user installed. Next you have sandboxing (if properly applied) protecting the user until they install the update (which might be some time).
You can also SXS the application in case you want to (ie some feature in the app was removed or changed but you want the new version too).
Layered security is the biggest plus here though.
The user might as well just be forced to run your "solid and preditactable baseline system" as his desktop system.
Containers may be massaged to work on servers because at the end of the day most interaction between server programs happens using TCP/IP (sigh). This is an entire different story with desktop programs.
Well that input library is not an issue of the flatpak environment but an issue of the application and/or that library. That error could have easily occured if the application linked an old version of that library and the new version of the daemon was incompatible.
Drag and drop works with flatpak to my knowledge, as does running something as default program for opening a file or URL. And window manager decorations work fine for my flatpak apps too.
The user would not be forced to do that if Linux system devs got their shit together. At the moment, Linux is barely a end-user desktop because everything beyond opening a webbrowser (and maybe not even that) is complicated. Configuring default fonts requires me to sudo'ing a text editor into an /etc file and manually insert the right incanations into an XML format.
Many subsystems in the linux desktop haven't been properly updated in quite some time and lag behind modern developments.
This is an issue Linux created because everyone makes their own solution and then distro managers will silently patch over the mistakes, so it all kinda works together.
The IME issue can be solved by making portals versioned, so flatpak can install the app with a runtime that contains a version of the IME lib that works. Similarly for other IO between the host services and client libraries.
Additionally, portals can already provide a number of things (drag and drop for example) without having to compromise security or convenience.
I would also like to point out that not every input method library the user has is going to break every single revision.
But that wouldn't happen in a distro-packages environment, because the distribution would ensure that everything was built against the same version of the library.
> This is an issue Linux created because everyone makes their own solution and then distro managers will silently patch over the mistakes, so it all kinda works together.
And flatpak is yet another case of that - doing their own incompatible thing instead of fixing what's there already.
This does not ensure that the library is compatible with the package, it only ensures that it builds.
>And flatpak is yet another case of that - doing their own incompatible thing instead of fixing what's there already.
They are working on standards that would improve things regardless of whether you're in a container or not. For example, the flatpak portals generally work just as well if you don't use flatpak at all, so apps don't care if they are inside our outside it.
This is part of the Freedesktop initiative on various things around Linux, which is already followed by quite a majority of desktop apps (and CLI apps), so there is a standard that improves things as they are.
Portals give you a standard way to interact with the user and the system that don't rely on distro specific patches.
You only have to test 1 system configuration and you can easily script building your app based on this configuration.
My life is certainly easier since I've packaged several apps into docker containers, even if it was a pain to get started on that.
- security library updates update with the base OS, which I update religiously and images are rebuilt (via "make") whenever the base updates, too
- the apps are effectively "somewhat" sandboxed
- I only bind-mount the directories I want the app to have access to (i.e. -v "$HOME/Pictures:/home/user/Pictures", -v "$HOME/.config/appname:/home/user/.config/appname" etc)
While this isn't ideal for graphical apps due to needing sharing the X11 socket for things to work well, which comes with its own type of problems...
... at least no app can change _my_ bashrc, simply because it can't even see it, nevermind edit it.
Going one step further, some bind mounts can also be mounted ":ro" to ensure the app cannot change the contents.
It all works, and provides some benefits (it is also fun, if you're into sysadmining!), but it kind of breaks one of the basic promises of "dockerizing" - that the containers are independent of what the host looks like.
e.g. I cannot just take the Dockerfile for a video streaming app container from my desktop with a Nvidia GPU, and use it as-is on my laptop with an Intel GPU.
I have 50+ "update-foo" scripts for programs that want me to use yet another package manager. Everything that doesn't use apt is in there, so many of them just run "pip install foo" or "npm install foo", at least this way I don't have to remember which program uses which package manager.
I used to be very adamant that if something did not have an apt repository then I wouldn't use it, but that's become hard to do. Even the piece of software I use the most, my browser, is not managed by apt. Firefox (developer edition) lives in ~/.local/lib and updates itself.
BTW, I used to think that we can just provide a prebuilt binary to let user download from a website, but finding that isn't easy to achieve unless you use a language like Go, Rust... because I found that many C program are hard to compile with full static linking.
Snap/Flatpak were meant to solve that issue.
Edit: There's also the fact that practically most packages on Ubuntu or Debian, for example, are outdated.
This "issue" was already solved by static executables. Snap and flatpack are the work of computer illiterates.
What I value most is having every software or library available through some form of package manager. Downloading static binaries off the internet without auto-update just doesn't make it which is why I like having Flatpak as a fallback.
It also makes it easier for the common user to have every piece of software available through one store. They don't need to know whether it's a .deb or a Flatpak underneath, it just needs to be there and work reasonably well.
There's really no other option: either distro maintainers include every single piece of software in the repositories (unlikely), or we need a common format that works on all distros (already the case with Flatpak).
On the maintainer/author side, yes, I think static binaries largely perform the same.
And they do? Just because they have some flaws doesn't mean that they're completely unusable. If you need an app that isn't on your distro but is on Flatpak, by all means use it.
Some reasonable level of quality control does take time. There are distros that are much more up to date with upstream versions (Arch Linux, Gentoo, etc), but by living on the bleeding edge, you will eventually get cut.
Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.
And it is easy to fix - publish capabilities in the gallery. Apple iOS "request location" shows that people care if they know. Sandbox certainly is a good thing. Without it Flatpak is just another package manager.
> It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.
https://en.wikipedia.org/wiki/Flatpak
> flatpak(1):
> ... isolated from the host system ('sandboxed') to some degree, at runtime.
> One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment.
https://docs.flatpak.org/en/latest/sandbox-permissions.html
And a lot more
Maybe we can trust big names, just like on Android — Google, Amazon. We may think that it is safer with paid software — they have something to loose. But free - I'd bet on maintainers.
The old thinking was that software was a user agent, serving the user's needs and interests. Some OSes (Debian comes to mind) explicitly acknowledge this.
Increasingly it's simply a naive and unjustified belief. Applications must be considered as untrusted necessary evils. Allocating them a minimum level of access is prudent.
Flatpak promises this, but fails to deliver.
Package managers offer this by convention, but rely on users (and security researchers) discovering and reporting malicious behaviour. Mitigation is retroactive: fixed behaviours or packages removed from the distro's repository, but the damage is done and existing deployments remain.
The underlying issue is one of packaging, updating, and distributing sandboxed apps.
And in recognising that packaging systems serve users, not developers.
FlatPak has Runtimes/SDKs for this, Snap has the one true Canonical-controlled base snap.
What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box.
Plus, they also add reproducibility, which is not to underestimate.
Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox.
BTW +1 for PPA culture.
What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution.
It's totally possible to hide a backdoor in an open source software.
A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.
not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think)
I disagree. Source auditing is irrelevant for day-to-day software use.
Fedora has such repositories (RPM Fusion, Copr). Arch does, too (AUR). Other distributions, including Debian, can use them as well, so long as there exists a community.
Compared to that Copr is a real PPA where you can build stuff into personal repo (as long as its built from source, licensing is fine & the thing is not patent encumbered).
Most popular distors provide similar stuff to PPA, the AUR in Arch for example.
It is rpm-specific, but not Fedora-specific.
With PPAs, everytime someone runs sudo apt upgrade, they are giving root privileges to their machine to some random person on the internet. No, having users scan the source code every time a package is upgraded is awful.
I reiterate, the most popular PPA is an old 3rd party Java PPA which doesn't even offer Java anymore. That PPA has root access to thousands of machines.
Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs).
If one likes to scream about administrative privileges to get attention, they're forgetting that any Linux user is giving root access to thousands of packages. So the point is really the web of trust.
If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst".
If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do.
This is really the concept of maintainers and their network, it's applying to the distro you're using, and it's nothing fundamentally different.
It was from a podcast from Canonical's apopey who described precisely some of the technical decisions behind snap and why they never bothered to open source it after the disaster that was open sourcing launchpad. He knows the statistics because most of these 3rd party PPAs were hosted on Launchpad that was only run by Canonical.
>Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs).
Systems like this should be designed for 99% of users. PPAs were designed for 0.1% of system admins, and developers, not users. They are absolutely awful UX design, they are inherently unsafe, and unreliable.
Expecting users to vet that software is safe just because the source code is available is flatly a stupid idea. 99% of users for any piece of software will have no idea what they are looking at and are incapable of vetting it. Have you vetted manually chromium, vlc, firefox, vscode etc?
Publishers on PPAs don't test against every distribution, and if they publish a package or dependency that breaks system libs than users are stuffed. Users would have little recourse. I doubt every ppa owner tests 14.04, 16.04, 18.04, 20.04 and 20.10 builds to check their ppa won't break anything.
>If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst".
Which has inspired both RedHat and Canonical to try and move towards flatpaks/snaps instead? The reason malicious attacks aren't there is because ppas aren't that popular because for good reason people tend to main repos.
Already on snap there was evidence of people bundling a cryptominer that was detected by Canonical. You think nobody has ever attempted to build/publish malware through ppas? Please.
>If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do.
My web of trust is purely Canonical. I chose it when I downloaded their OS. I trust their repos and snap store. I don't need to trust random Russian PPA for any reason. If a dev wants to publish something newer, put it on the snap or flatpak store or I won't use it.
I mean, Launchpad could be modernized and brought to the 21st century but all the functionality is there. I'd love to hear arguments against it though :)
Notice in the table regarding sandboxing. Someone is telling porky lies here.
https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-...
https://news.ycombinator.com/item?id=23520603 (3 months ago)
- The fact that GNOME Software says things are "Sandboxed" without further information is (gasp) a GNOME Software issue. And I don't think anyone is all that happy about it. In fact, there's a redesign pending, but resources are limited. GNOME Software is a rickety old beast and needs love, but it would be nice if people weren't trying to tear down surrounding projects as a result?
- Good job finding a security vulnerability. Please report an issue with the gitg Flathub repo[2], and with freedesktop-sdk[3], respectively. Congratulations on your amazing contribution! Have a free t-shirt before they run out [4].
- Speaking of Flathub, there is a discussion to be had about Flathub's lackadaisical approach around submitting stuff (and updating it). Maybe write about that? Or, better yet, don't write about how it's terrible and kills babies: write about how we can solve this stuff. For example, we could add some better backend tooling for Flathub that checks for unpatched libraries. Flatpak makes this sort of thing pretty doable. The Flatkill guy seems to have some experience with that, so, maybe that can be his next contribution (after he reports those two issues in their respective bug trackers). Heck, "Flatkill" is an okay name for a vulnerability scanner, so we're halfway there.
- To clarify, it's okay giving these things shit in your spare time, but once you're running a domain and spreading fear and uncertainty for dubious reasons (when being constructive is actually less effort), you're just being an asshole.
[1] https://news.ycombinator.com/item?id=24658052
[2] https://github.com/flathub/org.gnome.gitg/issues
There are comments there indicating https://www.reddit.com/u/-luv- as the author.
I agree it's absurd to have a sandbox system that doesn't protect the home directory [1]
Browsers and smartphones have an advantage here, because every app uses their file-open and file-save dialogs. If the user wants to open /home/user/pictures/whatever.jpg the sandboxed code gets access to that file and that file only, with the user's explicit consent. And if the app's file formats and suchlike don't match that way of working, tough luck because there's no alternative.
Whereas on Linux, where there are already 6+ other ways of packaging and distributing your app, a new entrant doesn't have the power to dictate terms or force developers to change their programs. And distributing a version of Gimp that couldn't open files in the user's home directory would be absurd.
If your application is inside a sandbox, it communicates with another process that presents the file chooser and hands over permissions based on the user's selection.
It is possible to choose directories in the same way, and portals are always improving: https://github.com/flatpak/xdg-desktop-portal.
Plenty of Flatpak applications actually do use this, but the author of this website loves to pick out the ones that don't so he can act like the project is flawed to the core and justify his sensationalist domain name. But actually it is very solvable, it is being solved, and in many cases you can tighten an application's sandbox with a two line diff.
Later edit - just to be clear, it's the kill part that I have a problem with. For example, name it flatrepair and developers will likely see your statements as something constructive.
This is completely backwards. Security features and encapsulation are the responsibility of the operating system. Never of the individual applications nor the package maintainers. A good, secure, operating system should be able to run hostile apps safely. For all its shittiness and complexity, this is something that browser developers got somewhat right.
Apps can use some low-level calls to the OS, to do things that cannot be replicated in the same way in a sandbox. So it is not surprising that some parts of apps must be rewritten.
If they are not rewritten, they just don't work in the sandbox. That's exactly the goal of a sandbox. Provide safe API for applications, and block apps that are trying to access more.
The options here are:
1. Run those things directly as OS packages or sometimes AppImages or just precompiled binaries.
2. Run them via flatpak.
3. Don't run them
I don't think 1 is more secure than 2, and 3 is not really something I care for.
So sure, Flatpak has it's issues, however I still appreciate it and IMO it is better than snap and AppImage. I also use AppImage for some things where the sandboxing of flatpak gets in the way too much, but snap never worked for anything that I tired it with.
To state that an application with full access to the host's filesystem is "sandboxed" is surely very harmful and very misleading.
The author is also mistaking Gnome Software (the gui for managing apps in gnome that has a flatpak backend) and flatpak itself. Marking the app as Sandboxed when it's not is a gnome software issue, not flatpak.
edit: since you mentioned Snap I assume Ubuntu. What's wrong with `sudo apt-get install inkscape`?
inkscape 1.0.1 via the snap maintained by the inkscape devs that will continue to get upgrades and give me options to switch over to edge releases if I want them (currently 1.1)
It depends - do the apps in version 1 dynamically link to system libraries that can be kept up to date? If they do, they may be more secure than the flatpak versions. If they simply come as statically linked blobs, then you are right.
It's very likely for openssl ;=)
> I don't think [running apps directly as OS packages] is more secure than [running apps via flatpac]
The article's claim is that running them via flatpak _is_ less secure because they don't automatically get security updates when the distro's libraries are updates and, as a result, they're less likely to receive prompt security updates. Do you disagree? If so, why?
E.g. they likely will not bundle openssl but use the systems openssl.
The Flatpak model is terrible for distros who are already strained for people and who benefit from factoring as much of the work as possible out of each application so you only have to update one place and push out a fix everywhere.
My distro either does not have the things I use from flatpak or have them with some deficiency (like older version or compiled features).
I can still get rpms for some, like Teams, but that also comes with bundled libraries and the Teams flatpak does have very tight restrictions so if I am concerned for the rest of my system flatpak is more secure.
For some other things on that list there are no rpms however.
So yes, you are more exposed to the maintainers behaving well, but you are also more insulated than just running things without any sandboxing.
Plus, you can have rpms that provide their own packages, but it's rare and will still be upgraded if it's in the repos.
It's not though. And for Teams filesystem access is serverely restricted only allowing access to xdg-downloads.
It's either a .deb, a .rpm or the snap store. Where do you find the flatpack?
I know that I downloaded the .deb (Ubuntu 20.04 here.)
I checked what I got installed now
ii slack-desktop 4.9.1 amd64 Slack Desktop
By all means, use flatpak, but be aware you are seriously degrading your environments security.
For me: I have discord and spotify installed via snap, with standard (not classic) confinement, and have had zero issues whatsoever with them. I also use VSCode and DataGrip via snap w/ classic confinement, and all of these work flawlessly.
I also have Slack installed, with classic confinement. It had issues with clicking links causing a separate Firefox process to be launched, rather than re-using the one I already had open. This was resolved with a config change inside firefox (weirdly enough), and is a common issue. Otherwise, it works great.
Development tools like node and go, those are another story. NodeJS is officially distributed via snap, and appears to run relatively well in classic confinement, but I've also ran into some really strange issues where, for example, a node process starting a child node process either silently fails or takes multiple seconds to start up, which causes issues in our company's testing framework. Go is not officially distributed, but is kept up to date by the community, but has major issues interfacing with VSCode (even though both VSCode and Go are in classic confinement!)
Overall, I really think Snap is a massive step forward in package management for linux. About 80% of applications I use are available there (versus maybe 40% on apt, 50% on apt if you include "run these dozen commands to use our custom apt server because we derive pleasure from making life miserable for our users" and 20% on flatpak). But, it has very obvious issues even non-technical users would see immediately. Hopefully they can work through them.
On my laptop with a latest gen ryzen cpu and nvme ssd, the Chromium Snap takes 30s-1 mins to launch, while the .deb launches in under a second. Same for Spotify, Discord and others that I've used. The start up time is so bad that I replaced them all for .deb versions which has been much better.
Snap startup overhead is a known issue. Its definitely a thing.