Don't use Appimages (a writeup about all the reasons they are a pain for users)

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.

drwankingstein,

oh boy here we go I strongly disagree with this article

While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.

.tar ARE messy, sometimes they don’t work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO

Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.

Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don’t appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.

see above

Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged “Windows workflow” (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.

Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME…

This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don’t have updater services, as package managers are way better at doing that.

I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.

This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn’t need that, or to have no updates at all.

Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?

Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn’t that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.

Appimages don’t even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.

I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a “curated” service. So we can grant one here.

There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages… you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn’t break.

This is how you get malware.

the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

They are not well maintained

There is a well known “bug” on modern Ubuntu, where Appimages lost their “works on every Linux Distro”, because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.

An application format, that is incompatible with the latest version of its core dependency, is broken.

This is a very minor issue, i’ve had way more issues with traditional repo packages then I have had with appimages.

Lack of Sandboxing …

I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.

Random location …

Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong. …freedesktop.org/…/basedir-spec-latest.html

Duplicated libraries

Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don’t share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.

This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.

and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

Appimages are not needed Flatpak solved many Linux desktop issues at once …

None of these provide reasons as to why appimages aren’t needed. Appimages still offer a lot, for one I can just download and run it I don’t need to worry about installing and uninstalling application when I just want to try it, I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don’t want to support, Users don’t need to download a stupid appstore or use CLI (not a single appstore i’ve used to date isn’t hot garbage, I hope cosmic-store will be different).

GenderNeutralBro,

I agree with much of this. However, regardless of which platform you’re on. it’s best to follow the design patterns of that platform.

Putting binaries on your desktop is not in keeping with Linux design patterns, nor are self-updating apps. I think those are fair points.

Having dozens of apps all using their own update mechanism introduces unnecessary complexity, which can be exploited. This has been a problem on Mac and Windows over the years. On Mac, for example, a common solution to this is the Sparkle framework, which devs can use in their app to manage self-updating; but Sparkle itself has been exploited, so then you have apps out there running god-knows-what-version of Sparkle in their bundles, leaving users vulnerable with no good way to identify or remediate it. This is why I typically disable any self-updating feature in any apps I use.

Pantherina, (edited )

Dont know where user installed tar archives (with statically linked binaries or including deps) would have dep conflicts, maybe if they are not statically linked.

The self updating stuff and desktop icons is personal opinion and not the common way on Desktop Linux, so I skip that.

you could do something like obtanium for android which could easily automate the process.

That is called a package manager, with a repo, with gpg signing etc. On Android (which I mentioned) updates are secure. Let alone the point that appimages are not updated in a regular way, they are just replaced.

I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe

No the difference is huge. If you are used to downloading software from websites, a faked website can easily lead to downloaded malware. Flathub can be added with a click and flatpak is included in distros, which means no hunting on the internet and no accidental clicks.

And as I said, until nobody downloads .flatpak packages online, and there may be an occasion where this is normal behavior, people will believe malware links are legit.

the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

Appimages are distributed everywhere, just as .exe files for Windows. This means they are favored by developers used to Windows and Mac, and those will not add them to a repo instead.

So a faked website of whatever etcher or something is easy.

The fact that Linux malware is not a thing, while Appimages clearly give the headstart for that, is a miracle.

I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything

Flatpaks are not secure because their sandboxes are weakened to not have such issues. This is due to apps not following secure standards, and until that is fixed they are insecure or broken or both. (Apps need to write configs in the container, they should use portals etc.)

I maintain a list of flatpak apps following modern standards, which is a small portion but getting better.

Linux is only somewhat secure because everything is FOSS and comes from repos.

This is broken by appimages, that can easily distribute malware and thus fix the “my malware is not running on that distro” issue.

Every software that can write to your .bashrc can easily catch your sudo password.

Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong.

Yes linux experts would put them there. As mentioned in that text malware would also install itself there, so on secure systems this should be only writable by root/ some elevated group privilege.

But apart from that users put them on the desktop, or in some random folder, I mean that dir is hidden for a reason.

Or put it in that PATH and then link to the desktop, resulting in a broken link when you remove the app.

When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

If something is not scaleable its not a good concept. The fact that you will only install a couple of appimage apps is enough proof.

On modern atomic distros users can rely purely on flatpak.

Btw see the linked dedup checker. You may download more dependencies but they are linked between each other and not actually take up so much space.

I don’t need to worry about installing and uninstalling application when I just want to try it

We need to overthink those habits. You dont just “try an app”, you run unsandboxed code from an unverified origin. As mentioned above, this could be totally fine, and also add a function to your bashrc that catches your sudo password (the next time you use it) and sends it to a server.

The secure way to do that is completely unpractical.

  1. Get a GPG app or use the cli, create a personal key. Secure the access permissions, as gpg always complains on Fedora for example.
  2. Hunt the internet for the gpg key of the dev
  3. Look for at least another source of that key like GrapheneOS does it
  4. Compare those keys hashes using cli or some app
  5. When correct, load the key into gpg/kleopatra/kgpg
  6. Verify the key with your internal key (yeah gpg is overcomplicated)
  7. Download the appimage, and a signed hash (most of the time its done like that)
  8. Verify the signed hash
  9. Sandbox the appimage using bubblejail (doesnt work) or firejail (no idea if it works, and its insecure)
  10. Repeat on every damn update (if it doesnt have a builtin updater)

This is unusable. And repositories do this automatically without anything you need to do. For sure you could “extra check the website” and say "

Also app data will be everywhere, often in its traditional location, while there is no package manager at all to delete them. Flatpaks store all their stuff (when devs care and not just ignore that, cough Cryptomator) in their container and data can be easily removed during uninstallation, GUI stores show a popup to delete data and I also made a small script to do that.

And that “try it out” app will either have no desktop entry or that entry needs to be manually and will be still there after uninstalling.

I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

This may be a reason, but this is only for testing then. But for sure, when its a small project, getting it on Flathub may be much efford.

I can imagine the developer experience is easiser. Flatpaks are simply very “defined” and need all that metadata and more to be complete. But needing to use available runtimes is a good thing mostly, its basically supporting a specific distro.

Flatpak through CLI is fine (I would like to have a standalone small store just for flatpak), Discover is nice too. The Linux Mint store also seemed fine but not much experience. (Linux Mint has some Wayland support now, so there is a secureblue Cinnamon spin, have to try that). The Cosmic store is just a stub currently, lets see!

Cheers!

smileyhead,

AppImage is a nice way to have an app on an USB stick, remote server or for archival. But for normal app usage, why?

Pantherina,

I want to find a way to do this with flatpaks too.

A small GUI tool (a statically linked binary lol) that can be placed on that stick

  • copy the flatpak app and runtime stuff to a folder
  • copy the desktop entry over
  • copy app data when chosen

And the same thing to copy it from the stick to a live system. Should work, probably not haha

smileyhead,

TIP: Flatpak have a build-in way for creating USB, check out the “flatpak --help”.

But the point is with Appimage all that have to be installed is FUSE, which is expected to be installed on most installs when you go to a friend or work where Linux is used.

Pantherina,

Oh nice!

Flatpak also works everywhere and appimages are not ported to fuse3…

I mean I want to think Appimages where nice, and they are kinda, but no.

oldfart,

Why do I hear the argument about no .desktop entries in every thread like this? Creating a .desktop file is a requirement for the appimage creation tools to work, and appimaged installs it in the system menu immediately. It’s seamless.

MonkderZweite,

Does flatpack finally let me choose an alternative to ~/.var?

Pantherina,

Explanation?

MonkderZweite,

Needed to have zulip to talk about a bug, the AUR package was a pain to debug, the appimage in ~/.local/bin just works™.

Tiuku,

The only use case for Appimages
If users want to carry applications around on a thumbdrive, or run on a fully immutable system like TAILS, Appimages may be needed. But this is the only target, and it is not a standard use case.

I guess I agree. This is precisely the case where I have ever used them. Namely to have a portable executable of my password manager on a stick together with a backup of the password database.

I had no idea they were being used elsewhere.

Pantherina,

Nextcloud, Balena Etcher, Lunar Launcher and more are exclusively supporting Appimage, thats the big problem.

eugenia,
@eugenia@lemmy.ml avatar

Some of these apps can’t work as flatpaks at all, because they require more access to the system, e.g. Davinci Resolve. AppImage allows that. I mean, heck, even Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing. So, yes, there are cases where AppImages do serve a purpose. Not most cases, but a lot of cases.

kopasz7,

Are these access problems not solvable with XDG portals?

yukijoou,

because they require more access to the system

afaik, you can allow more system access to flatpaks

Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing

i believe flatpak also does that, you can specify some paths from the host to be available to the flatpak

Pantherina,

Have a look at GPU screen recorder, I think thats as much privileges as you need.

XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.

If the Davinci Resolve devs actually cared about Linux…

Pantherina,

Have a look at GPU screen recorder, I think thats as much privileges as you need.

XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.

If the Davinci Resolve devs actually cared about Linux… I think the best way to run it is using uBlues image on Podman.

Atemu,
@Atemu@lemmy.ml avatar

I don’t get why we didn’t just do it macOS style; bundle everything into one directory with a standardised structure and wire up file managers etc. to run the correct executable inside it.

Kazumara,

Because the FHS is a more sensible organization of files. Not every user needs to have their own executable for each program, that’s a mess.

2xsaiko,
@2xsaiko@discuss.tchncs.de avatar

macOS has both, a system wide /Applications and per-user ~/Applications. Not to mention that it doesn’t really matter on a single user system anyway.

Atemu,
@Atemu@lemmy.ml avatar

Proper, integrated packaging is obviously preferred (though as a NixOS user I disagree that that implies an FHS) but this is about “stand-alone” packages. You’re missing the point.

smpl,
@smpl@discuss.tchncs.de avatar

opt

TheAnonymouseJoker, (edited )

I do not agree. AppImages can be double clicked and executed. They are not a pain to use. I have a few dozen AppImages besides a few Flatpaks and plenty native packages on Debian. Comfortable setup that carried over from Ubuntu LTS.

This poster advertises GrapheneOS propaganda, and I never take those security weirdos seriously anyway, so either way I do not consider their security arguments as valid. All of these people have a common theme – pushing people towards becoming dependent on them, their “repositories” and apps, forming cults around it and becoming self-approved security gurus and dishing out moronic advice.

If there was a way for these people to be able to rebrand one of the non-native packaging formats, they would shill the fuck out of it, just like GrapheneOS.

yukijoou,

AppImages can be double clicked and executed. They are not a pain to use.

i can understand that, but flatpaks are easier to upgrade and automatically integrated into your package manager, which (i believe) isn’t as straight forward for appimages. also there’s one major repo where you can find most apps (flathub) making app-hunting less daunting i feel like.
also, once your app is installed, it’s always in your system menu, so that doesn’t change much in the long run

Comfortable setup that carried over from Ubuntu LTS.

can’t you carry over flatpaks as well? you can probably copy /var/lib/flatpak or wherever they store their stuff from one system to another, or failing that, save all the app IDs you have installed, and re-install them onto your new system, backing up ~/.var to keep all your data!

sxan,
@sxan@midwest.social avatar

Flatpack puts all app data in ~/.var?? Ewww! No thanks.

yukijoou,

not sure about the path, you should check flatpak’s docs for more accurate informations

but i believe so, yeah

on one had it’s a shame they’re not using xdg dirs, but on the other, i kinda get why – it’s neither config files, nor just data – it’s both, it’s a container

TheAnonymouseJoker,

I preferred a clean slate Debian installation. I had other Flatpaks with doubled version dependencies as well, which I got rid of. I believe that we should opt for the most frictionless workflow, and use best tool for a job. (Of course 🖕 to anti-privacy stuff as much as feasible.)

Two nice Debian+Windows 7/10AME machines with lots of privacy, solid security and a great amount of freedom😌 feels like Pareto frontier is achieved, but still want to see if minimal modifications can make things even better, so I could update my Linux/Windows computing guide.

onlooker,
@onlooker@lemmy.ml avatar

Counterpoint: I don’t like having more than one package manager on my system, which means things like Flatpaks and Snaps are out. With AppImages, I just double-click on the executable and off it goes.

FooBarrington,

I get that multiple package managers can be suboptimal (though I don’t have a problem with it as long as the integration is good).

But it still seems like a much, much better solution than just not having these applications managed by a package manager, as is the case with AppImages.

onlooker,
@onlooker@lemmy.ml avatar

True. I would consider another package manager if it integrated into my system nicely and if I had more than a few applications outside my regular package manager. But I only have like two AppImages on my PC anyway, so I don’t mind updating them manually when I need to run them.

FooBarrington,

That is the case for me with Flatpaks. They integrate really well into Fedora Kinoite - you have OS updates and Flatpaks all in a central UI, everything works as expected from any “App Store”.

Pantherina,

Thats flatpak with flathub. Also described in the post

dino,

Most shortsighted answer of the day. Great now you have this outdated executable on your system and you mabye are not even sure this was installed through appimage, because how should you know when your launcher is not telling you anything? golfclap

delirious_owl,
@delirious_owl@discuss.online avatar

You should definitely be checking the signatures before double clicking tho

Pantherina,

So you prefer to not have any updates or secure verification, because you dont want a second package manager?

Dude you are the second package manager, and if you dont follow the whole gpg verification process I described in another comment, that is less secure.

thiccckk,

I use Appimage this is a tool which make it easy to install Appimage and update it

github.com/ivan-hc/AM

dino,

When the description of a program on gh gives you more headache…I think its not doing a good job.

atzanteol,

I’ll be voted down but…

This is the shit you get from kids who grew up with “app stores.”

Vincent,

Lucky kids. I remember when I switched to Linux and encountered my first app store (Synaptic). That was already such a huge improvement over random .exes, and app stores today are way, way better.

mexicancartel,

Damn even i was impressed by apt install command so much the first time

atzanteol,

Package managers are fine. Walled gardens are not.

Vincent, (edited )

Absolutely. Luckily there are plenty of non-walled garden solutions on Linux, e.g. Flatpak.

Pantherina,

I mean, snap could also be not. Just somebody needs to write a wrapper that allows to download, verify etc. .snap packages from other repos.

Shitty move of Canonical for sure.

Jegahan,

What the hell are you talking about? Did you even read the post? They literally praise native package managers, statically linked binaries and even .tar archives over appimages. If you don’t have any actual arguments against their point, you don’t have to make shit up, you know? Using BS ad hominem to dismiss someones opinion isn’t a great look.

atzanteol,

Oh I read this overly-long breathless whining alright. Could have been like 3 bullet points - 1 of which is “doesn’t create an icon for you”?

Oh my God how do I run things without an icon to tap? That “terminal” app is scary!

Jegahan,

Man what a braindead take.

Firstly, you’re not adressing the fact that your BS Ad hominem didn’t even make sense. You’re calling OP a “kids who grew up with “app stores”” when they are talking about prefering to get a .tar over appimages. You’re now even doubling down with “That “terminal” app is scary!”. I know having actual arguments is hard, but maybe just think for a second before writing something, particularly if you’re so desperately trying to be snarky.

Secondly having to using the terminal is fine for experienced user who like the efficiency of it and makes sense for more advanced cli apps or development tools, but for app that are meant for an average it’s just a needlessly shitty experience. Same goes for having to look up the website to download a random package from the internet that you’re going to run uncontained on your system. Given how easy it is to game the SEO to land at the top, this is just begging for a virus and is an absolutely garbage system.

And it really doesn’t need to be this way given that we already have better working alternatives.

atzanteol,

Man what a braindead take.

Yeah - probably. Not everything is Shakespeare.

Pantherina,

You also dont use the Terminal for Appimages, its all shitty GUI patterns taken from Windows UX.

yukijoou,

i think those kids got a point – app stores are easier than finding random executables on the web

it can sometimes be a pain to find the original developper’s website to get a legitimate copy of the software from, especially for non-technical users.

the main issue with app stores is that they’re often closed ecosystems, where there’s only one app provider. that’s not the case with flatpatk!

Pantherina,

The linux people and their repositories…

OR3X,

App Images do suck, but I don’t think flatpak is much better. It’s more of a lesser of two evils situation. Snap isn’t even in the conversation.

skullgiver, (edited )
@skullgiver@popplesburger.hilciferous.nl avatar

deleted_by_author

    •
    Pantherina,

    Agree. But support by distros would make them acceptable. Only if they tick the basic security requirements of a repo, actual maintenance and download verification, this should be done.

    Icons on Wayland are not possible, because of security. Apps could spawn a window that looks like Chromium and ask for a password, for example.

    Do they need desktop entries, DEs should absolutely not create them for those apps.

    Yes I think I touched the library issue a bit, but this is really bad. There is no updating system that could tell you what apps are affected too.

    avidamoeba,
    @avidamoeba@lemmy.ca avatar

    AppImage is great at what it does - provide an ultra-low effort packaging solution for ad-hoc app distribution that enables a developer who won’t spend the time to do rpm/deb/flatpak packaging. There are obvious problems, security and otherwise, that arise if you try using it for a large software collection. But then again some people use things like Homebrew and pacstall unironically so …

    iopq,

    Great, now tell me why your appimage is complaining about not having some .so file on my system

    avidamoeba,
    @avidamoeba@lemmy.ca avatar

    The developer made extra low effort and missed a lib. 😅

    iopq,

    No, the problem is more subtle, the developer assumed I have the same libs in the same locations as a mainstream distro like Ubuntu, but I do not

    I actually have several versions of each library in different hashed folders (my distro does this) and I just steam-run normal Linux executables

    Except I can’t do that when using this appimage thing so it doesn’t directly work on my system

    avidamoeba,
    @avidamoeba@lemmy.ca avatar

    Well, theoretically if the developer had bundled the libs they assumed would be present on Ubuntu into the AppImage, maybe it would have worked. Would it be larger? Sure. 😂

    Throwaway1234,

    But then again some people use things like Homebrew and pacstall unironically so …

    Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!

    Pantherina,

    Post about homebrew by Jorge Castro

    I am not sure how secure it is.

    Throwaway1234,

    I am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.

    Btw, I don’t really understand why you felt the need to share Jorge Castro’s blog post on Homebrew? AFAIK it doesn’t go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that’s known to be non-conforming when security is concerned. While I haven’t seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I’d refer to as) ‘old habits’; which is exactly what Homebrew allows. It’s worth noting that, during the aforementioned search process, they’ve made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there’s reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn’t come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the ‘uBlue-way’ of doing things)…

    j0rge,

    I’m not a security expert but I do know that the Homebrew is working with openssf on security: openssf.org/…/alpha-omega-grant-to-help-homebrew-…

    Boxkit predates wolfi so it’s still alpine, I’ll probably replace it at some point but most of the forks of boxkit are because people want the premade github actions and they end up replacing it with whatever distro they want anyway. The wolfi connection is because I know the people who work there (including a ublue maintainer) and we have similar goals/ideas on how linux distros should be put together. My ideal dream is a wolfi userspace systemd-sysext on top of fedora base, then we can have our cake and eat it too!

    We’re not security experts but lots of us work in the field and that gives us access to peer review from experts when we set things up. We sign every artifact with sigstore so users can verify that the code used in github is what’s on their image, that sort of thing. And most of our practices utilize CNCF governance templates that lots of other projects use.

    Pantherina,

    I learned quite some things from this talk

    youtube.com/watch?v=4WuYGcs0t6I&t=456

    Appimages are damn broken

    avidamoeba,
    @avidamoeba@lemmy.ca avatar

    I mean, I’m not saying they aren’t. I think the original argument is valid. I just think they’re better than the alternative, which isn’t Flatpak but self-extracting .sh files.

    Pantherina,

    Yes thats true. But that talk specifically mentioned the horrible security practice of appimages, and that they dont run everywhere at all

    avidamoeba, (edited )
    @avidamoeba@lemmy.ca avatar

    No argument. The security aspect is something that seemingly a lot of people in this thread don’t get. The some-person-creates-a-package-I-install model works as reliably as it does without sandboxing only when that person is a well known trusted individual or group. For example the Debian maintainers team. It’s a well known group of people who are trusted due to their track record to not produce malware-ridden packages intentionally or unintentionally. That is the line of defense you got. If you remove that, you end up in download-random-shit-on-Windows land in regards of security.

    What’s worse, this extends to the bundled libraries. Unlike central systems with shared libraries like Debian, bundling libraries means that the problem extends to the sources of those libraries! Package A and package B both include libjpeg-v1, it’s got a remote exploit gaping hole. Developer A has time to follow CVEs and updates theirs. Developer B doesn’t or has moved on. The system gets a patched libjpeg-v1, app A gets it, assuming it can be auto-updated. App B remains open for exploitation.

    Therefore given all that, sandboxing is a requirement for safely using packages from random people. Even when the packages from those come from a central source like Flathub or Snap Store. Sandboxing is why this model works without major security incidents on Android.

    Anyway, won’t be the first bad practice advocated by some in this community.

    Pantherina,

    This matches very well with this talk of an OpenSuse microOS maintainer doing a followup on his thoughts of Appimages, Snaps and Flatpak.

    Spoiler: Flatpaks are the only ones that work.

    avidamoeba, (edited )
    @avidamoeba@lemmy.ca avatar

    Snaps work too if you use Ubuntu and trust Canonical, as he mentions. I’m a bit annoyed at Flatpak for being inferior to Snap in that it can’t be used to install system components. Snap allows for a completely snappy system, without the need to build the base OS one way and the user apps another. The OS from-traditional-packages, user-apps-from-Flatpaks model is an unfortunate compromise but I guess we’re gonna get to live with it long term. It’s better than the status quo.

    BTW I completely disagree with him that everyone should be using rolling releases. As a software developer, user, and unpaid IT support, this is a mind boggling position.

    Pantherina,

    Yesno. Snaps are not sandboxed at all, which is a nogo for normal application distribution.

    So while I think it also sounds nice to pack an OS into different immutable parts, if the entire system is flawed, its not worth it.

    Flatpak is good for app distribution, the rest is job of the OS.

    not rolling release but normal stable release, not some random LTS. Not every software is like Firefox ESR (which honestly is not needed as Firefox doesnt break), but Debian etc. often just randomly dont ship updates.

    Fedora is a bit too rolling, but if you always stay on the older supported version, thats okay. Especially with atomic.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • fightinggames
  • All magazines
    •