GitHub - trytomakeyouprivate/dont-use-appimages: Appimages are an insecure packaging system with very limited use cases. Please use Flatpak instead!
github.com
Appimages are an insecure packaging system with very limited use cases. Please use Flatpak instead! - trytomakeyouprivate/dont-use-appimages

Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.

Their use case is tiny, and in 99% of cases Flatpak is just better.

I could not find a single post or article about all the problems they have, so I wrote this.

This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.

  • @Pantherina@feddit.deOP
    9•9 months ago

    GearLever](https://github.com/mijorus/gearlever) solves all the problems mentioned.

    Sceptical but I will try it for sure.

    It makes appimages less worse than Flatpaks though, so its only “badness reduction” for me.

    There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.

    The first is what I mentioned, such updates can be perfectly done by a central package manager. Did you ever try to seal off a Windows install using Portmaster, where every installed app needed network access for their individual update services? Just no…

    Ans to the repos, yeah maybe, havent looked if they are as secure as a linux repo. But the concept of “it is acceptable to download software from random websites” allows for malware to fit in there. Only if you will never find a .flatpak file it is possible to be sure its malware.

    But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.

    All worse than bubblewrap. Containers are either manual af (like with bubblejail) or if you refer to Distrobox/Toolbox, unconfined by default. They have no portal integration and no GUI configuration apps. So it may work somehow but probably worse, more resource heavy and there simply already is something better.

    Same for VMs. Keep an eye on Kata containers, but this is about least privilege, not some QubesOS system that will not run in a tablet, for example. Android uses containers, is damn secure, and runs on phones.

    [non executable stuff]

    This is about protecting against malware. Linux Desktops are built on a different logic. Any unconfined software can download a binary to localbin, copy a random desktop entry from usrshareapps to your local folder, edit the exec line and add that binary to it.

    Or just manipulate your .bashrc, change the sudo command to read input, save to file, pipe input to sudo. Tadaa, sudo password stolen.

    That concept of “users can change their home but not the system” is poorly pretty flawed. So any directory that is writable without any priveges is insecure, if you dont trust every single piece of software you run.

    Agree that Snaps are a problem. Its only really problematic when repackaging is illegal though, of course annoying but the Spotify flatpak is a repackaged snap. Same as with appimages.

    I should write the same about snaps, but I feel they are covered WAY better.