When I first started using Linux 15 years ago (Ubuntu) , if there was some software you wanted that wasn’t in the distro’s repos you can probably bet that there was a PPA you could add to your system in order to get it.
Seems that nowadays this is basically dead. Some people provide appimage, snap or flatpak but these don’t integrate well into the system at all and don’t integrate with the system updater.
I use Spek for audio analysis and yesterday it told me I didn’t have permission to read a file, I a directory that I owned, that I definitely have permission to read. Took me ages to realise it was because Spek was a snap.
I get that these new package formats provide all the dependencies an app needs, but PPAs felt more centralised and integrated in terms of system updates and the system itself. Have they just fallen out of favour?
PPAs are flawed and limited to the Debian/Ubuntu ecosystem. They’re a security issue as you really need to trust to the person or group who has set up the PPA (yet many people just added PPAs for all sorts of random software based on a Google search). They need to be maintained which is variable depending on the size of the project and for developers they’re only a route to support part of the entire Linux ecosystem. They can also conflict with the main system provided packages and repost which can break entire systems or break upgrades (happened to me on Mint, and I needed to do a complete system reinstall to remove legacy package conflicts).
They’ve fallen out of fashion and rightly so.
There are other ways to get software to users. Arch has its AUR which is basically a huge open repo. OpenSuSE has its OBS which is also a huge open repo. These are also not without their risks as it’s hard to curate everything on such an expansive repo. However others can take over packages if the original developer stops updating them, and you can see how the package was built rathe than just download binaries which allays some security concerns. They are also centralised and integrated into the system, while PPAs are a bit of a free for all.
Flatpaks are a popular alternative now - essentially you download and run software which runs in a sandbox with its own dependencies. Flatpaks share their sandboxed dependencies but it does lead to some bloat as you’ll have system level libraries and separate Flatpak versions of the same libraries both installed and running at the same time. However it does mean software can be run on different systems without breaking the whole system if library dependencies don’t match. There are issues around signing though - flathub allows anyone to maintain software rather than insisting on the original devs doing so. That allows software to be in a Flatpak that might otherwise not happen but adds a potential security risk of bad actors packaging software or not keeping up to date. They do now have a verified tick in Flathub to show if a Flatpak is official.
Snap is the Canonical alternative to Flatpak - it’s controversial as it’s proprietary and arguably more cumbersome. The backend is closed source and in canonical control. Snaps are also different and for more than just desktop apps and can be used to in servers and other software stacks, while Flatpak is focused only on desktop apps. Canonical arr also forcing Ubuntu users to use it - for example Firefox only comes in a snap on Ubuntu now. It has similar fundamental issues around bloat. It has mostly the same benefits and issues as Flatpak, although Flatpaks are faster to startup.
Appimage are another alternative way to distribute software - they are basically an all-in-one image. You are essentially “mounting” the image and running the software inside. It includes all the libraries etc within the image and uses those instead of the local libraries. It does and can use local libraries too; the idea is to include specific libraries that are unlikely to be on most target systems. So again it has a bloat associated with it, and also security risks if the Appimage is running insecure older libraries. Appimage can be in a sandbox but doesn’t have to be, unlike Flatpak where sandboxing is mandatory - which is a security concern. Also Appimages are standalone and need to be manually updated individually while Flatpaks and Snaps are usually kept up to date via an update system.
I used to use PPAs when I was still using Ubuntu and Mint. Now I personally use Flatpak, and rarely Appimages, and occasionally apps from the OBS as I’m on OpenSuSE Tumbleweed. I don’t bother with snaps at all - that’s not to say they don’t have value but it’s not for me.
Edit: in terms of permissions, with Flatpak you can install Flatseal and manage software’s permissions and access per app. You can give software access to more locations including system level folders should you need to or all devices etc for example. I assume you can do the same with snap but I don’t know how.
Also you can of course build software form source so it runs natively , if you can’t find it in a repo. I’ve done that a few times - can be fiddly but can also be easy.
Or use nixpkgs.
Or glorious nixos.
Or one of its many forks now that they went ultra-woke!
/jPpa’s are Ubuntu… Debian is not Ubuntu even if Ubuntu is Debian
Another issue I’ve had with Snaps is just increased boot times. Something to do with mounting all the virtual images involved or something, makes boot take noticeably longer. I’ve tested having an Ubuntu install with Snaps, and then removed the snaps and snapd while installing the same software via Flatpak, and had a noticeable boot time improvement. Hopefully they’ve been working to improve this, but it just soured me on them even more.
As for another install method, mostly for CLI tools, but working with a lot of GUI apps too now, there’s Distrobox. It has a bit of a bloat issue, because you’re basically installing an entire extra headless Linux Distro with it, but it for example allows you to run AUR inside an Arch based Box, and then you can integrate the app you installed with AUR into the host OS, running it near seamlessly, while keeping its dependencies contained in the Box which you can easily remove. By default apps in the Box will have access to the host’s filesystem but you can mitigate this if you want. Distrobox is especially great on atomic read-only Distros, where you can’t directly touch system directories, by allowing you to install apps that expect such access from things like AUR.
Jia Tan liked your comment
Without the traditional distribution workflow what prevents flatpaks to be full of security issues? Unfortunately sandboxing cannot protect the data you put in the application.
You are aware that the xz exploit made it into Debian Testing and Fedora 40 despite the traditional distribution workflows? Distro maintainers are not a silver bullet when it comes to security. They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.
I am well aware of it. It is an example of the traditional distribution workflow preventing a backdoor from landing into Debian Stable and other security-focused distributions. Of course the backdoor could have been spotted sooner, but also much later, given its sophistication.
In the specific case of xz, “Jia Tan” had to spend years of efforts in gaining trust and then to very carefully conceal the backdoor (and still failed to reach Debian Stable and other distributions). Why so much effort? Because many simpler backdoors or vulnerabilities have been spotted sooner. Also many less popular FOSS projects from unknown or untrusted upstream authors are simply not packaged.
Contrast that with distributing large “blobs”, be it containers from docker hub or flatpak, snap etc, or statically linked binaries or pulling dependencies straight from upstream repositories (e.g. npm install): any vulnerability or backdoor can reach end users quickly and potentially stay unnoticed for years, as it happened many times.
There has been various various reports and papers published around the topic, for example https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities/
That is what we do and yes, it takes effort, but it is still working better than the alternatives. Making attacks difficult and time consuming is good security.
If there is anything to learn from the xz attack is that both package maintainers and end users should be less lenient in accepting blobs of any kind.
Even if Snap was completely open it would not change anything. Snaps are overly complex and way to complex. Flatpaks on the other hand are fairly simple because it uses bubble wrap for isolation.
obvious bot account is obvious.
snaps are so much worse AND less trustworthy it’s not even funny.
Appimages don’t bloat the system, they are actually many times even smaller than native packages thanks to their compression (librewolf being 100 MiB instead of 300 MiB, libreoffice being 300 MiB instead of 600 MiB).
And those are “lazy” appimages made with linuxdeploy, if you do some tricks with static linking to can get their size down way way more. For example one case is qbittorrent, their official appimage is 100 MiB while there is a fork called “qBittorrent Enhanced Edition” and they got the size of the appimage down to 26 MiB
I also don’t know what you mean by security risks with the libraries, the appimage gets made in CI (usually ubuntu 20.04 or debian stable) and the libraries from those distros get bundled and released, the only way this could be a security risk is if the whole appimage is outdated or debian/ubuntu haven’t caught to updating their distros.
My big issue wiht flatpak is that they don’t follow the xdg base dir spec and neither add the binaries to PATH (And they said that they will not fix those issues btw), making them only useful for some graphical applications, while pulling several gigabytes of runtimes and dependencies, and the more I’ve been using and understanding appimage the more I think both flatpak and snap should have never existed. As 99% of what they do could have been done with appimage already and just keep a centralized repo of approved appimages for security concerns.
deleted by creator
Former OS security chief here.
Please, God, avoid flatpaks, appimages and snaps. They break rules just to break more rules, and you’re the victim.
Flatpaks are always going to be better than just installing random software of the Internet. This is true from both and security and reliability context. Software inside flatpak only has the permissions it needs which is a example of least privilege. Furthermore chances are you are getting the software from flathub which more trustworthy than some random repo. If someone tried to do something problematic such as a fake crypto app it will likely be caught.
@possiblylinux127 @corsicanguppy
Does Flathub curate all their packages?
Yes, to some extent