This is why this problem exists, this kind of apathy of “it’s not my problem” and we end up with a convoluted user experience.
Hey, we can’t force distributions to add support for AppImage files, can we? So the only chance we have is that many users start using AppImages, and at some point will create enough “pull” so that distributions will start to care. If you have a better idea, iI’m all for it
Just executables without the executable flag in general should be handled better. I wonder what are the thoughts of the leading distributions on this.
I think calling it “user-hostile” is a bit hyperbole. If you think about it, every installation system requires some kind of user training to use it.
- Download an exe/msi, double click, “whoa there, would like to install a pointless toolbar?”
- “hey you want to install Java? Does this app need Java? no but want it anyway?”
- “hey want flash too?”
- and so on.
- There could also be issues with malware being attached to an installer so common suggestion is to tell people to scan the software before running/installing.
- Download a DMG, extract the DMG into an uncompressed folder then manually move all of the contents into an Applications folder.
- Play Store, search and read through reviews to make sure the app isn’t garbage. Then install and upon first launch agree to various permission settings . . . typically blindly.
- Go into developer mode to turn on external APK installs and then find an APK somewhere.
and so on and so on.
Sure there is a bit of user training needed for AppImages but all that training requires a 30 second conversation or a 15 second demo gif.
- Download AppImage, right click choosing Properties, go to Permissions tab, click the make executable checkbox. Now it’s ready to be used.
I think this is by FAR the least user-hostile of all the options available for any system.
It would be nice for a more useful message to popup saying to do that in order to launch the AppImage but that’s something the distribution would need to implement unfortunately.
DEBs have their own issues like for example:
- Does the user know if they need 32bit or 64bit?
- Is the user using Ubuntu based distro or Debian based?
- Is the user using Ubuntu LTS or a non-LTS?
- Does the user know that DEBs for different versions of Ubuntu don’t work in other versions?
- Does the distro they use have gdebi installed or a software center of some kind? (if no, then double clicking a deb for install won’t work)
Many of these come up often and create confusion for users.
Let’s say for example you are providing the DEB which alleviates all of the above issues because you already have the information and are providing the DEB. Your complaint is about needing external input but in this case you would be the external input.
Whether you solve these questions for DEBs or give them a gif to look at for giving executable permissions, both are external input.
This isn’t apathy, this is not having the ability to modify the distro infrastructure. The goal of AppImages is to be usable across as many distros as possible. Compromises are needed to make it as simple as possible to do so and I think AppImages achieve that very well with very little user training needed to use them.
This would be ideal because the more developers and users that use AppImages the more distros have to pay attention to how AppImages are being used and how to improve support for them.
This is actually a security feature of Linux. People can’t just download a program and run it without explicitly saying “yes you can run”. This is a good thing because it means people also can’t accidentally download a virus and the virus launch itself and infect the system. If a user downloads a virus or somehow one gets on their system then literally nothing will happen because the program has no permission to run.
If you give a DEB file to someone they still need to provide permission with a user password and in some cases even that makes people be cautious to run something.
If AppImages were made to have an exception for example then viruses could just be packaged as AppImages.
Ultimately, there is a reason for not allowing executables to have default permissions to be executed. However, the unfortunate situation of not informing a user of how to give said permission is something that could hopefully be fixed provided that distros were willing to implement a solution.
In my opinion, the good out ways the bad in terms of manual permission setting and when it comes to user-training it is by far the easiest approach I’ve ever seen.
AppImages coming from trusted sources should be installed without any additional steps. In the other cases there should be possibility to force the restriction by using Alt-key (or similar) or explicitely by hitting kind of “Install anyway…” button, like in macOS. Requiring “chmod +x” is problematic. Sudo password must be required for apps modyfing system files.
AppImages aren’t really ever technically installed so the process is easier than standard packages in my opinion.
However, the ability to give exceptions to trusted sources would depend on the distro to implement that and it would require someone to curate a list of trusted sources.
I think if there was a warning to tell them they need to grant the AppImage permissions that would be enough. It’s not difficult to do.
It’s not a requirement. Users can use the GUI method which does not require sudo at all.
AppImages don’t need sudo to run and they don’t even need to be installed at all. The only barrier to entry is the “make executable” situation that I feel is important for security and so easy that it shouldn’t really be a barrier especially if a user knows to do that.
We need to ask developers to include the how to make executable when they distribute their AppImages even if it is just a link to that thread I linked.
The more and more people who use AppImages then the more and more who will be accustomed to the make executable permission need and this issue becomes a moot point.
How would you do that?
Sorry @MichaelTunnell but you are completely missing my point in all of your replies.
My point is: without external input, I cannot download and run an AppImage as-is. Why? Because the OS simply does not let me execute it and does not tell me how to proceed.
Windows guides you through, you double-click on stuff, dialogs happen, you get to a result in the end. macOS guides you through - you double-click on the dmg, a dialog pops up, easy enough.
Linux distros? You double-click and you get nothing. Nothing guides you to making the software executable. Nothing but external input: instructions you read beforehand or Googling after the OS has successfully blocked you from doing what you wanted to do.
I’m not here to undo the whole security model, but why not guide people to making the binary executable? Pop up some dialog saying “Yes I want to run it”? It’s not a novel idea - on-demand dialogs granting root permissions, a far more dangerous thing, already exist!
Unfortunately it relies on distros to implement a solution but I would be fine with a popup that said “To ensure security, you’ll need to grant permission for this AppImage to run.” Then there would be a button that says “Learn How” and that button could simply direct to the gif or whatever.
Of course, it would be better if there was a more simple way of doing it . . . maybe a popup that asks for user password to automatically apply chmod in the background, maybe.
To clarify, when I said “it’s not difficult to do” I was referring to the action of making it executable not getting this warning to be implemented.
I didn’t miss the point at all. I have already expressed that the distro would need to implement some sort of functionality that addressed this issue. It’s not possible to force the distro to show a warning for the AppImages so if this were implemented it would unfortunately have to be done via the distros themselves.
My point about Windows and MacOS is that you still have to learn something in order to use them. Once this single concept of making executable is learned it doesn’t need to be learned again. I think you are exaggerating the size of the barrier that this is. It is a barrier but, in my opinion, it’s not “user-hostile”.
I agree that it totally is an issue but it’s an issue that requires outside implementation with distros in order to solve it. I wish that wasn’t the case but unfortunately it is. I suppose to best course of action for this is to the AppImage team to decide how they want to present a message that it needs to be done and then ask the distros to implement said message.
I would bet the AppImage team would love to be able to do that.
AppImages use the filetype “.AppImage” which is not recognized by most distros as a known filetype. The distros would need to recognize it as a filetype and invoke actions for that filetype based on whether it has permissions set correctly or not.
You’re right it’s not a novel idea but it’s also something the AppImage team does not have the ability to implement. This is something a distro has to want to implement and do so.
I don’t think many distros have even considered this as a feature to add because sadly many distro developers weren’t even aware of AppImages until a couple years ago and in some cases less than a year ago. I know one of the Fedora developers was discussing which was better Snaps or Flatpaks and someone suggested he look at AppImages and he said “what’s an appimage?”
Now many many more people are aware of AppImages but unfortunately many people still don’t understand how they work so distro developers may be aware of them now but might not be aware of this barrier for them. I suppose advocacy to these distro developers would be the best tactic.
With all that said, there is a workaround but I think it is kind of a messy workaround that I would rather fix the filetype issue than for this workaround to become the normal.
An AppImage can be set as executable and placed in a tar.gz archive. A user would download the tar.gz archive, extract it and the AppImage would be runnable without changing permissions.
There are many issues with this but most notable is that most open source software shares the source code of the software as tar.gz and having the same archive type to be the binary and the source code would be confusing.
This also would be an issue of having to teach people that you need to extract the archive . . . this would likely open up an archive software tool but they would still need to figure out to extract it.
Example: Etcher does it this way with a tar.gz archive. http://etcher.io
Yes, and they should do this for all ELF files (applications). Then it will be fixed for AppImages as a side effect. And with “distributions” you probably mean desktop environments such as GNOME, KDE Plasma, etc.
So if you would like to see this, please open bug reports there.
Please DO NOT do this. It destroys most of the advantages of AppImage:
While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional
appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything.
That’s a good point and for the DEs if it is isolated to the file managers supporting formats then yea I guess that’s what I meant.
I’d be fine with making bug reports.
I agree completely. I wasn’t suggesting it, I was just saying it was possible but I think it is a terrible approach overall and creates more issues than if solves.
With just a claim and no information - I don’t see why zipping is a bad idea. It preserves the executable bit and less convoluted to tell someone to unzip a file rather than go dig deep in file properties. File archivers job is to intuitively let people archive/extract and I don’t see it as an issue to leave it up to them.
Agree this should apply to any ELF binaries and not just Appimage.
People need to understand that the executable bit (a) is there, and (b) is a security feature. Any method of bypassing the need for the user to give explicit permission should be seen as extremely bad practise.
Imagine downloading a zip archive that contains
image.png, which is actually an executable in disguise. You double-click the image to view it and instead the executable runs and deletes everything in your home directory. The fact that (some) archive formats preserve the execute permission is arguably a security flaw, and one that AppImages should not seek to exploit.
All that really needs to happen is someone writes a patch for
nautilus (GNOME Files) to give a more helpful message when someone double-clicks on an AppImage (or on any ELF binary) that doesn’t have execute permission. The message could be something like:
Execute this file as a program?
For security reasons, this program currently does not have permission to run on your computer. If you know where it came from and trust the source, click here to grant permission.
A message like this should pop up even if the user is running
appimaged, in my opinion. This is equivalent to the warning given on a Mac when the user tries to run an untrusted
Would you be able to write this? I wouldn’t even know where to start.
I approached the Nautilus developers. They were friendly and welcoming, but they said that all platforms (Windows, Mac, Linux) are moving away from allowing untrusted executables to run outside of a sandboxed environment. It is highly likely that quite soon, Nautilus will no longer have the the ability to launch programs by double-clicking on them, even if they DO have execute permission. This means the question of prompting for execute permission is moot, because the program won’t run anyway.
They suggested this course of action:
- Add the AppImage MIME-type to the open-with list for a sandbox program.
- Double-clicking an AppImage runs it inside a sandbox.
- Add the AppImage MIME-type to the open-with list for GNOME Software.
- Double-clicking an AppImage opens GNOME Software and asks if the user wants to install the AppImage.
It may also be possible to modify the spec slightly to make AppImages valid
snap packages, but fully self-contained so that they can still be run independently of those packaging tools.
The bottom line from the lead developer for Nautilus was:
csoriano: [with] respect to the file manager: sandbox with perms framework? ok to run, otherwise, no
Sorry to barge in, but how about making small application that can be registered as handler for AppImage mime type? One that would just display window with big “Run It” button and some sandboxing options.
I’m asking because I’ve drafted something like that and come to check if there is any interest for it, finding this thread as first thing
Registering a handler for the AppImage mime type would technically be an option, but since it would have to be installed on the system, why not let the optional
appimaged daemon handle everything automatically. We could integrate a GUI similar to what you are showing there; but even better we would make it “just work” like on the Mac without asking the user questions.
In any case, please avoid the word “install” in conjunction with AppImages, since they don’t need to be installed.
Sorry, I was under impression that is not (currently?) possible. If that’s not the case, I have nothing to offer
Benefit of using mime type handler would be, that appimaged would no longer need to watch directories. It doesn‘t matter which directory the appimage is saved to.
I think a mime type association with a handler is the better approach, since it relies on basic mechanisms offered by any DE. After all, double clicking a txt or png file is one of the most basic tasks, thus mime handlers can be considered pretty mature.