{"id":21887118,"url":"https://github.com/boredsquirrel/dont-use-appimages","last_synced_at":"2025-03-22T02:15:17.218Z","repository":{"id":225896580,"uuid":"766883225","full_name":"boredsquirrel/dont-use-appimages","owner":"boredsquirrel","description":"Appimages are an insecure packaging system with very limited use cases. Please use Flatpak instead!","archived":false,"fork":false,"pushed_at":"2024-03-04T22:36:03.000Z","size":38,"stargazers_count":13,"open_issues_count":1,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-01-26T20:23:26.704Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/boredsquirrel.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2024-03-04T10:01:52.000Z","updated_at":"2025-01-22T09:38:07.000Z","dependencies_parsed_at":"2024-03-04T21:42:06.301Z","dependency_job_id":"18347f7f-78da-465f-94cb-4f1a265cf8f7","html_url":"https://github.com/boredsquirrel/dont-use-appimages","commit_stats":null,"previous_names":["trytomakeyouprivate/dont-use-appimages","boredsquirrel/dont-use-appimages"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/boredsquirrel%2Fdont-use-appimages","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/boredsquirrel%2Fdont-use-appimages/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/boredsquirrel%2Fdont-use-appimages/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/boredsquirrel%2Fdont-use-appimages/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/boredsquirrel","download_url":"https://codeload.github.com/boredsquirrel/dont-use-appimages/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244894311,"owners_count":20527678,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-28T11:08:29.766Z","updated_at":"2025-03-22T02:15:17.196Z","avatar_url":"https://github.com/boredsquirrel.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Don't use Appimages\nAppimages are an insecure and user-unfriendly packaging system with very limited use cases.\n\nThis is a list of reasons not to use them.\n\n### What are Appimages?\n\nA packaging format similar to direct executables / portable Apps on Windows, or statically linked binaries.\n\nThis concept was quite anticipated, as it allows to run apps on all Linux Distributions.\n\nThat this is just as possible with statically linked binaries, that are possibly faster, is often ignored. [Firefox](https://www.mozilla.org/de/firefox/download), the [Jetbrains Toolbox](https://www.jetbrains.com/toolbox-app/download) and many more binaries work perfectly fine, but Appimages got a hype for whatever reason.\n\n### Usability issues\nWhile 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.\n\nApps 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/`.\n\nAppimages have no desktop entry, so they have ([currently](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52)) no icon on Wayland and they don't appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.\n\nInstead users follow strange habits like placing the files on their desktop, which is a highly discouraged \"Windows workflow\" ([symbolic image](https://www.firstclasstechnologies.co.uk/wp-content/uploads/busy-desktop.png)) and not even supported on many Desktop Environments, most notably [GNOME](https://linuxiac.b-cdn.net/wp-content/uploads/2023/09/gnome45-desktop.jpg).\n\nThis means that in the end users need to create their own .desktop entries, that will\n- not get updated\n- not get edited when an \"update\" changes the name of the appimage file (Appimages have no name!)\n- and not deleted if you delete the .appimage file.\n\nExample of such an entry\n\n```bash\ncat ~/.local/share/applications/someapp.desktop\n[Desktop Entry]\nType=Application\nName=SomeApp\nGenericName=Some description\nComment=\"$GenericName\" #(yes you need both for different DE's)\nExec=/home/username/some-random-directory-probably-named-Apps/appname-version-architecture.desktop\nIcon=/home/user/some-random-directory-probably-inside-the-app-dir/some-random-icon-also-not-an-svg-from-some-random-website-edited-with-gimp.jpg\n```\n\nCreating one manually it not fun.\n\n### Updates\nThis 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. 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.\n\nInstead users need to follow an RSS feed, get a mail, or **manually check for updates**, which is horrible UX. Then how do they update? \n\n### The lack of repositories\nAppimages 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.\n\nWith Appimages, Linux users that always laughed about Windows malware through shady downloads, are catapulted back into that stone age too.\n\n**Linux users should never download random software from the internet**. This is like rule No. 1.\n\nThere 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.\n\nThis is how you get malware.\n\n### They are not well maintained\nThere is [a well known \"bug\" on modern Ubuntu](https://www.omgubuntu.co.uk/2023/04/appimages-libfuse2-ubuntu-23-04), 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. \n\nAn application format, that is incompatible with the latest version of its core dependency, is broken.\n\n### Lack of Sandboxing\nAppimages use fuse, which [doesn't seem to work](https://github.com/AppImage/AppImageKit/issues/152) within a [bubblewrap](github.com/containers/bubblewrap) sandbox. ([Firejail is not recommended](https://madaidans-insecurities.github.io/linux.html#firejail)). Even [hacky attempts](https://github.com/igo95862/bubblejail/issues/8) to isolate them with [bubblejail](https://github.com/igo95862/bubblejail) needed to degrade the bubblewrap security model by running then in a root sandbox, and no fix was found in over 2 years.\n\n**Appimages to this day run completely unconfined**, while (as mentioned above) their chaotic and unverified origin makes them **the perfect tool to distribute malware** on Linux.\n\n(There already was malware [on the Snap store](https://www.bleepingcomputer.com/news/linux/malicious-package-found-on-the-ubuntu-snap-store/).)\n\nAlso, integration is important. Flatpaks can now be used and configured completely through the GUI. Appimages will not get that level of GUI tooling anytime soon. They have graphical tools, but those are incomplete.\n\n### Random location\nEven immutable distributions are far from the security of Android. A necessary step would be mounting the entire `/home` non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?\n\nThere would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.\n\nWithout any system integration, Appimages can not be installed into a dedicated, secure directory (like flatpaks are).\n\n### Duplicated libraries\nAppimages 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.\n\nThis also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.\n\n### Appimages are not needed\nFlatpak solved many Linux desktop issues at once\n- [runs on nearly all distributions](https://flatpak.org/setup)\n- [sandboxes apps](https://docs.flatpak.org/en/latest/sandbox-permissions.html), using bubblewrap\n- permission system with GUI integration ([KDE Settings](https://userbase.kde.org/Tutorials/Flatpak), [Flatseal](https://flathub.org/apps/com.github.tchx84.Flatseal))\n- lots of [verified Applications](https://flathub.org/de/apps/collection/verified/1), that are officially supported (no downstream packaging issues)\n- discoverable through a central repository with no restrictions, support for [many more repositories](https://github.com/trytomakeyouprivate/flatpak-remotes)\n- shared libraries, [using deduplication](https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker)\n- uses [Appstream metadata](https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html) for **an app name**, description, changelogs, screenshots and more\n- Flathub has a rating system, displays the used license and a lot more. It can be filtered by `verified`, `floss` and `verified \u0026 floss`.\n\n**Flatpak is by default installed** on Fedora, OpenSuse, Linux Mint, Debian, Pop!_OS, TuxedoOS, EndlessOS, ElementaryOS, PureOS, Solus, VanillaOS and more.\n\nIt is established and won't go away.\n\n### The only use case for Appimages\nIf 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.\n\nThis would theoretically be possible with flatpaks, but not currently implemented.\n\n---\n\nThere are many projects repackaging Appimages as Flatpaks, and those can then be maintained by the original developers.\n\nTo all developers considering using Appimage for \"their linux version\":\n\n**DON'T**\n\nPlease just use Flatpak, save us all the trouble and support a modern Linux desktop.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fboredsquirrel%2Fdont-use-appimages","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fboredsquirrel%2Fdont-use-appimages","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fboredsquirrel%2Fdont-use-appimages/lists"}