- 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.
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.
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.
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 $*"
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.
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.
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).
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).
/snark
I get the idea of Flatpak. I want some kind of app sandboxing. Ideally with a good UX and shared libraries, however.
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.
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.
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.
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.
Now is flatpak secure for installing closed source app? At least not when they have full x11 access when using x11 desktop.
> 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.
...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.
> 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.
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.
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.
.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 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.
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".
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.
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.
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.
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.
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
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.
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.
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.
> 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?
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.
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.
To state that an application with full access to the host's filesystem is "sandboxed" is surely very harmful and very misleading.
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 ;=)
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
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)
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.
By all means, use flatpak, but be aware you are seriously degrading your environments security.
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.
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.
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.
Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
..à 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.
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.
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.
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.
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.
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).
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.
Snap/Flatpak are just an unnecessary disaster IMO.
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
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.
All of the above however need resources (ie money) and that's why things are moving forward so slowly.
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)
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.
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.
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.
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.
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.
- 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.
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.
- 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.
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)
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.
