Why You Must Avoid Snaps, Flatpaks and AppImages
If your Linux distribution uses traditional software packaging (for instance, apt in Debian Linux), then you can do a security audit by examining the source code of each package installed in your system. This will take you ages to do because it is so much software... But at least you will audit each software library only once. That's because in such a system each library is found only once, and reused in all apps that need that library through dynamic linking. (Not absolutely so, but overwhelmingly.)
You know what is much, much worse? To use a package manager in which each packaged app comes with all its dependencies. Then packages are much larger and they repeat the same libraries, rather than reusing the one already installed in your base system.
Today nobody has patience for the thankless job of packaging software anymore, so they seek shortcuts.
Image packages
In this article, I will use the expression "image packages" to refer to this kind of packages – encompassing snaps, flatpaks, appimages and docker images.
The programming languages Go and Rust, when they were young, were unable to dynamically link libraries; they only worked by compiling the libraries directly into the binary of the app. This harms security in two ways: 1) when a bugfix in a library is distributed, the app continues to use the buggy version that was statically linked; 2) it is harder to know which version of a library is being used by the app binary.
When Linux distributions first appeared, everyone was aware that security is their main job. If you chose to run Debian, you knew your software had been validated, you could trust it. Debian stable is slow to update software, you keep running the same version of an app for a long time, which gives you more reason to trust that version. This is a good thing, but it makes contemporary audiences bored, since their consumerism also manifests itself in constantly updating one's desktop environment and seeing the latest pointless icons, images and animations. In the 2000s Linux grew beyond groups of people sensible enough to appreciate free software. Many creators of open source software today use Apple computers instead of Linux, allowing Apple to spy on them constantly. That's because these people's priorities are mistaken.
Specific Snap issues
Even in this bad zeitgeist, the community has been protesting Ubuntu's insistence in pushing their Snap packages. Here is a list of the problems with Snap, from least important to most important:
- Canonical has been criticized because the backend of the package store is proprietary software. (I am not sure anyone else would want to reuse that backend anyway.)
- Canonical forces snaps upon all Ubuntu users; Firefox on Ubuntu is currently a snap package.
- A snap package is slower to start – and I don't know if this can be helped, since most snap packages should run in a sandbox (which results in better security) and it is a much larger software blob with all its dependencies.
- All snap packages are much larger because they contain all their dependencies, wasting disk space.
- Canonical decided that the updating of snaps shall be entirely automatic; in this step they forget who their audience is, for Linux users want to be in control of their computer, instead of controlled by big tech companies.
- As we saw before, a snap package contains all its dependencies, making a security audit a nightmare.
These things should be reserved for unpopular software only. For instance, you want to early adopt something that has not been packaged; the developer, even though she does not have time for packaging, made a flatpak; so you reluctantly use it (by trusting the developer).
Linux Mint is a distribution based on Ubuntu, but they saw the writing on the wall and decided not to accept snaps. This means they are doing the work Ubuntu is now refusing to do: to properly put Firefox in a .deb package. Further, Mint started work on a "Debian Edition", which is not based on Ubuntu. Mint realizes that for a Linux distro to start using image packages instead of their traditional package manager... is terribly misguided and will have consequences.
And just 3 hours after I wrote "will have consequences"... I caught word of the incident:
The incident
YouTube video: Malware discovered on Ubuntu's Snap store
Basically, some villain uploaded a snap of a crypto app that asked users for their most basic crypto password, and someone lost USD 10k that way. The app theoretically may also have read the users' home files. Canonical encourages everyone and anyone to make snap packages and upload them to their snap store, with no security audit.
Almost everyone thinks snap packages are sandboxed (without access to a number of things on the system), but the truth is, sandboxing is correctly recommended, but can be turned off by the person making the package. Thus the video gets comments such as this:
@act.13.41: The whole reason we were given for having Snaps available ONLY on the Ubuntu Snap Store was the security of the apps. This should never have happened. PERIOD.
Could this happen in apt?
Could malware invade traditional package management too? Here are 2 great comments about this, from the video above:
by @skynetisreal: Typical case of quality or quantity. Those are choices you have to make as a repository maintainer.
by @knghtbrd: Yes, snap is bad, but this problem could exist on flatpak, it has happened in PPAs, has happened in random mirrors of trusted distributions… It could even happen in the AUR if someone was careful/clever. You need to be damned careful where you get your software.
Debian's primary repository has never had malware in it – but a random mirror was hacked and did get some malware in it once. That's why every Debian package is cryptographically signed when it's uploaded. Once uploaded, the sig is checked, logs are kept which key signed it, the package is hashed and the hash is stored in the package list. The list and release file are then signed to prevent tampering with repos. To put malware into the Debian package pool requires getting someone's GPG key or getting a malicious dev through Debian's process which includes checking someone's real name on government ID.
So Debian isn't proof against this kind of thing… but it's taken reasonable steps. If you go and add 3rd party repos, you're weakening that security. So like I said: People need to be careful where they get their software from.
Putting out the fire
Canonical's response to the incident (covered in the video) is that crypto apps (and only crypto apps) now temporarily shall go through an audit. This does nothing about all the other apps that can read your home files.
Further, a comment by @alexhajnal107 reads: 06:04 The new system as described is still flawed. With their new system one could upload a bootleg but unaltered version of an app. Since it isn't malicious it may well pass review. Wait until it gets a bunch of installs then upload a malicious update. Per their stated policy this will not undergo review.
However, Ubuntu's policy of forcing updated versions on users is actually helping them remove the malware app from people's computers. They simply created a newer version of the affected packages with no software inside. AFAICT there is otherwise no mechanism to even let people know what's going on.
At 9 minutes into the video we learn that a very similar incident had already happened in May 2018. That is 5 years ago – in all that time, practices seem not to have improved at all. Why would they improve this time around?
Lessons for us
This incident is the final stone on the tomb of Ubuntu's Snap project, as far as I am concerned. Whoever uses image packages should now be trying to understand the risks and seeking alternatives. But the general public today for some reason finds it difficult to learn certain lessons.
Trust in the software packages is the most important service provided by a Linux distro. By forgetting this, Ubuntu deserves their ongoing loss of public – and there are many alternatives out there.
When I use Linux, call me crazy, but... I want multiple people to have okayed the software I am running. This is probably why the thankless job of packaging software deserves even more thanks than we knew.
This happened to Snap, but I don't know whether FlatHub has different policies.
And if you use proprietary software, you have ultimately no idea what it is doing in your machine, since nobody has access to the source code, and the binaries are inscrutable. No big tech company currently deserves to be trusted since they are all spying on us and collecting facts about us and building even shadow profiles of us. If I sound paranoid to you, sorry, the truth is you are just ill-informed.
Nix as a good complement
The main problem with image packages is security; it is much easier to audit and trust a single package manager in which dependencies are reused. When dependencies are included in an image you have to trust the image, so the work is not just tripled or quadrupled, no -- the work is multiplied by the number of images you are using, times the number of versions in time.
This is one of the reasons I use nix as a second package manager to complement the main one in a distribution. I can find all the software I need in either apt or nix. That's better than using image packages.
NixOS is a Linux distro based on the nix package manager, which has great features for security audits. nix generates an ID (really a hash) for each package, based on its source code among other things. If the binary is no longer available for some reason, nix knows the git commit and the address from which to obtain the source code, and immediately proceeds to download the source code, compile it on your machine and produce the bit-for-bit exact same package whose binary was lost in time. I am still learning about nix but I would bet it's the best thing for security.