Possible additions to improve system integration with the AppImage spec

[mgord9518]

Reaching out to the AppImageKit devs: I absolutely love the AppImage format, but over my last 6 months or so of using them, I’ve found some fundamental issues that may be holding them back overall as an application distribution format, as well as some possible additions that could fix them without taking any abilities away.

Issues with current spec:

1. There is no standard way to request minimum permissions to run properly such as Flatpak does.
2. Integration with Firejail simply doesn’t work correctly most of the time. Most AppImages I’ve tested don’t even launch using it, and if they do, they lack the minimum permissions to function correctly without manually tweaking which can be intimidating to new GNU+Linux users, and AppImages are commonly targeted at them.
3. Although this is mostly an app developer issue, a lot of AppImages do not work on all common GNU+Linux distros. Application devs are ultimately the ones who should ensure this, but it doesn’t happen enough regardless and many AppImages just straight up don’t work on some distros.
4. There is no standard way to internally name applications such as the way native package managers and Flatpak do for centralized distribution (outside of the filename). For terminal programs, there is no standard way to request a launch command (such as being able to run ‘vim’ in the terminal to launch a vim AppImage), which ultimately requires users to write launch scripts.

Possible fixes:

1. Request app devs to add a manifest file inside the AppImage, which gives all the minimum permissions in order to run properly, an internal program name (possibly following Flatpak’s style of reverse DNS?) for package managers to use, and a request to add terminal command(s) so users can launch the application from the terminal with no manual setup.
2. This would be solved by solution #1. An optional launcher would be able to read the requested permissions from the AppImage, show the user what permissions are required, then launch the AppImage if the user agrees.
3. If possible, a launcher would be able to run AppImages inside a Flatpak jail. This would give AppImages a standard system to run in, and would always be guaranteed to work when ran inside, exactly how Flatpaks can reliably run across different GNU+Linux systems with different libraries.
4. This would also be solved by solution #1.

All additions would only be seen by a system launcher written around them, and the AppImages would still work exactly the same as they currently do without the launcher.

I believe these additions could allow for much better integration and security with less work for the user, but I’d love to hear your input on it. Frankly, I’m not a very good programmer, but I’d be willing to try my damndest at writing a proof-of-concept

[probono]

Hello @mgord9518,

thanks for reaching out.

There is no standard way to request minimum permissions to run properly such as Flatpak does.

This is because by default AppImage, unlike Flatpak, does not talke away any permissions.
Unless you actively choose to run them in somehting like Firejail.

AppImages do not work on all common GNU+Linux distros

Application developers using the AppImage format can decide which distributions to develop for, and which ones to support. If you encounter an AppImage that does not work for you, then please contact the application author that provides the AppImage.

We are testing the ones that are listed on https://appimage.github.io/ on the oldest still-supported release of Ubuntu.

There is no standard way to internally name applications such as the way native package managers and Flatpak do for centralized distribution (outside of the filename). For terminal programs, there is no standard way to request a launch command (such as being able to run ‘vim’ in the terminal to launch a vim AppImage), which ultimately requires users to write launch scripts.

You can rename AppImages and move them freely in the filesystem, or e.g., put a symlink to an AppImage intp /usr/local/bin with a name that you want.

We are not interested in “the way native package managers and Flatpak do” things nor in “centralized distribution”. In fact, the AppImage format exists so that appliction authors can give users the applications without the need for package managers nor centralized distributions, and to empower users to put AppImages wherever they please.

Request app devs to add a manifest file inside the AppImage, which gives all the minimum permissions in order to run properly

Yes, we had considered that idea before, but some kind of software would have to make use of this information. I am not aware of any such software, but in case you would like to help develop it, this would definitely be something that we would be interested in discussing.

Are you aware of the various existing AppImage consumption tools?
GitHub - AppImageCommunity/awesome-appimage: Lovingly crafted AppImage tools and resources lists just a few of them, and possibly your ideas could be integrated into one of those.

[Sonophoto]

As a long time unix user I would like to be clear that I like AppImage just the way it is. I have no problem configuring scripts and launchers to do exactly what I want to do and I don’t need AppImage doing things behind my back.

I don’t want to come across harshly, but frankly if someone wants to use Flatpak, they should just use that tool. If someone needs an “easy” OS then they should just use Windows. Unix (linux, BSD, ™ - whatever) has a philosophy, AppImage respects that philosophy. Full Stop.

[mgord9518]

I really appreciate the reply and information, I’ll start working on a little tool to read the manifest information. Is there any specific way it should be laid out? If not I’ll probably just try to implement it in YAML. As for the package management, I meant something similar to AIPM (not a centralized repository), but the extra information would just give it more to work off of

[mgord9518]

Apologies for any confusion, I wasn’t talking about AppImage doing these tasks, this would be done by an optional launcher or daemon. These additions would simply be a text file which wouldn’t effect the actual AppImage’s functionality in any way.

[Sonophoto]

Building a stand-alone launcher that read an optional txt file in an AppImage wouldn’t impact me at all; I am still left wondering why you wouldn’t just use Flatpak if it already does that.

The idea of running an app contained in a single wad (directory, archive, what have you) has been around for a long time and I think it is a glorious concept. “More Power to You”, I hope you succeed at solving your problem - I just don’t want the solution shoved down my throat.

[Sonophoto]

JSON?

Just a thought. Here is a lucid discussion of relative merits: The state of config file formats: XML vs. YAML vs. JSON vs. HCL - Octopus Deploy

[mgord9518]

Flatpak doesn’t offer portable applications, which is the appeal to AppImage. I don’t really understand how a <1KiB text file that simply offers a little extra information on the bundle is “shoving it down your throat” though, unless you were referring to something else

I’m considering JSON too, but I figured YAML would probably be better because it’s more readable and allows comments, which (standard) JSON unfortunately doesn’t.

[Sonophoto]

A optional txt file for an external 3rd party launcher doesn’t bother me at all.

– But trying to push changes onto an application to make it more like another application is a slippery slope. At this point I’m all claws – so I speak up.

Just my 2 cents, if YAML it is “more readable” why does it need comments? (lol) If you need out of band data seems like you could just have a string in the JSON named “comment”, “purpose”, or “instructions”.

[mgord9518]

Imo comments are a big factor in readability, it allows you to specify what a specific object is for, etc. While you can just add more strings in JSON as “comments” it’s kind of a hacky way to do it and it would be a lot more preferable if it was just an actual feature. YAML is largely just JSON with added features, and I also think the syntax is much better looking.

But yeah for the small amount of data that would be in the file I don’t think it would be a huge deal.

[mgord9518]

I’m currently working on a little bash script (then eventually a GTK launcher) to interpret this, but I made a mock-up YAML manifest if you’re interested in it. I think this extra information would be beneficial to a lot of AppImage consumption tools.

# Sample manifest file for The Powder Toy

# The point of this is  to  supply  extra
# desktop  integration  information  that
# isn't in the .desktop file.

# Unique identification for each AppImage
# bundle, which can also allow a daemon/
# launcher to ensure duplicate desktop
# files don't appear in your applications
# launch menu.
# The ID should probably be a flipped DNS
# of the  project's origin  website, just
# to try to minimize bundles accidentally
# using the same one.
bundle_id: "uk.co.powdertoy.tpt"

# The specific license of the bundle,
# examples would be "gpl", "gpl2", mit",
# "2cbsd" (2 clause BSD),  "4cbsd", etc.
license: "gpl3"

# The type of license. This is mainly if
# a bundle manager doesn't recognize the
# specific one used above. Can either be
# "proprietary", "mixed" or "free"
license_type: "free"

# Request a terminal command to be added
# by a launcher.  This  will do  nothing
# if no launcher  is  used and should be
# able to be rejected by the user.
# A launcher should also be  capable  of
# seeing if it's already  in  the user's
# $PATH and warning them if so.
command: "powder"

# Whether  or  not the  bundle  requires
# root access  to function. (should this
# even be an  option?  Or  just too much
# security risk?) I'm very  iffy on it..
# Can be set to [true] or [false].
# Note:  if  enabled, a launcher will be
# completely  unable   to   sandbox   it
# because, well, it's root.
require_root: false

# Request directory access to be granted
# by a launcher.
# These could easilly be implimented  in
# most sandboxes.
# Can be set to:
# ALL                # Would tell a launcher not to sandbox it at all
# sb-home         # Allow access to a sandboxed directory (necessary to save any information)
# xdg-config      # Should generally be avoided because it causes file fragmentation, but can be enabled for convenience
# xdg-desktop
# xdg-documents
# xdg-download
# xdg-music
# xdg-pictures
# xdg-public-share
# xdg-videos
# xdg-templates
# :ro and :rw(default) can also be added
# Ex: xdg-downloads:rw
fs-permissions:
  - "sb-home:rw"

# Any FS permissions granted through the
# sandbox will be bound to the  isolated
# home directory from the user's real home
# directory

[probono]

This partially duplicates already existing AppStream metadata.
Please see AppStream - Wikipedia.

[llothar]

“As a long time unix user” in other words as someone who is responsible for the 30 years of continous failure of Unix and Linux as a common end user system.

The problem is that a lot of people have different reasons for Linux and technically nerd guru magic is i guess very low. Most people don’t want pay Microsoft US$ 200 for a license, don’t want to send MS so much private data or simply don’t want to share any data with a USA based corporation. So whatever the change to appimage is it should be convenient first, cryptic configuration second. Nobody loves configuration files, often setting the executable permission is already too much (like for my nephew).

[probono]

Exactly, nothing should need to be configured. It needs to work out of the box.

As for the executable bit, please see

How to run an AppImage

Before you can run an AppImage, you need to make it executable. This is a Linux security feature. There are three main ways to make an AppImage executable: 1. With the GUI Open your file manager and browse to the location of the AppImage Right-click on the AppImage and click the ‘Properties’ entry Switch to the Permissions tab and Click the ‘Allow executing file as program’ checkbox if you are using a Nautilus-based file manager (Files, Nemo, Caja), or click the ‘Is executable’ checkbox if yo…

Ideally desktop environments (Gnome, KDE, Xfce,…) would ask the user whether a file should be made executable when an ELF (application) file is double-clicked that is lacking the executable bit.

Please request this feature from your desktop environment of choice in case it is not available there yet.

[mgord9518]

I ended up embarrassingly finding that out about a week after making that post. The implementation of my launcher will use Appstream for all data besides
A: What the AppImage already provides in the desktop file
B: The permissions an AppImage would ask for (unless there’s also a standard for that, I’ve just been unable to find it.)

As for the executable bit, I’ve seen a few AppImages that come as zip or tar downloads, which is a bit redundant, but it allows an easier way for brand new users (who don’t understand POSIX permissions yet) to launch it since the executable bit will be set upon extraction of the archive.

It would be really nice to see at least one DE ship with support for AppImages though, such as a “make executable and run” dialog. Like seriously how hard is it for them to throw something like that in? AppImages are a common format, and they’re recognized as different than normal ELFs under MIME type, so it would be pretty easy to associate them with a basic dialog upon launch as opposed to “there is no application associated with appimage MIME type”

[probono]

@mgord9518

I’ve seen a few AppImages that come as zip or tar downloads, which is a bit redundan

This is not recommended at all. AppImage was carefully designed so that you don’t need to unpack anything, which is a time and space consuming step.

It would be really nice to see at least one DE ship with support for AppImages though, such as a “make executable and run” dialog. Like seriously how hard is it for them to throw something like that in?

Trivial.

Please ask the developers of your desktop environment to implement such a dialog for ELF files (executables) that are lacking the executable bit.

It does not even have specific to AppImages. Could (and imho should) be implemented for all sorts of ELF executables (“binary programs”).

Please see Improve running binaries experience (#443) · Issues · GNOME / Files · GitLab for more details.

[mgord9518]

I don’t use a DE currently but I’ll probably end up suggesting the addition to some, and maybe PopOS would be receptive because they offer the Launch Keyboard software as an AppImage

[probono]

It’d be worth a try to open a feature request with PopOS then
Feel free to cc me.

[mgord9518]

I’ve opened a feature request on Github