Appimagekit: Proper handling of ELF files in desktop environments

[probonopd]

__If you care about this issue, then please open an issue ticket with your favorite desktop environment including a backlink to here, and add the URL to the ticket you have opened to this thread.__

• [ ] GNOME https://gitlab.gnome.org/GNOME/nautilus/issues/443
• [ ] KDE https://bugs.kde.org/show_bug.cgi?id=394672
• [ ] MATE
• [ ] XFCE
• [ ] Elementary
• [ ] Cinnamon
• [ ] LXDE
• [ ] ...

Currently our users have to set the executable bit before they can run an AppImage. This apparently is a real barrier for them.

Desktop environments should ask the user whether to set the executable bit and then run the application when the user double-clicks on an ELF file that doesn't have the executable bit set.

This is in no way limited to AppImages but also applies to other types of executables.

Vaguely similar to this dialog that Firefox brings up:

This is what Linux MINT users currently see, which is certainly not ideal:

It should instead ask "do you want to mark this application as executable and launch it?".

EDIT 18.05.2018: In https://gitlab.gnome.org/GNOME/nautilus/issues/443 this has been proposed for GNOME Nautilus:

[probonopd]

https://plus.google.com/+MarkShuttleworthCanonical/posts/7LYubpaHUHH

If GNOME / KDE were to make support for AppImages a first-class thing, then we would follow in the distro

It would entirely be sufficient if GNOME / KDE would support ELF files with the missing execute bit as a first-class thing. There is nothing special to AppImages in this regard. Download __any__ ELF file from the web, and you'll run into this.

though I think we would probably want to caution users appropriately regarding security

Certainly, e.g., by the way of something like the Firefox dialog box shown above. But don't make it too frightening. After all, installing a random .deb from the net means granting full root access to the machine, which is not the case with setting the execute bit to an ELF file.

[IGassmann]

Submitted ticket for KDE and Gnome.

[TheAssassin]

Thanks @IGassmann. Would appreciate if you posted updates here.

[probonopd]

In the GNOME ticket, someone writes

From my point of view, this is essentially requesting support to install an application bundled as an AppImage.

Please clarify in the GNOME ticket that this issue is __NOT__ about AppImages nor about "installing" applications nor desktop files and such, but about how to handle _any_ ELF file that does not have the executable bit set. This has __nothing__ to do with AppImages specifically.

[IGassmann]

@TheAssassin thanks for following-up with the GNOME thread! I'm surprised that an issue was opened 5 years ago and no progress has been made on this.

[TheAssassin]

@IGassmann no problem, but I'm a bit disappointed they decided to remove any handling of ELF files... this "app stores are the only way to use apps" mentality is really the opposite of AppImage.

[simoniz0r]

but I'm a bit disappointed they decided to remove any handling of ELF files... this "app stores are the only way to use apps" mentality is really the opposite of AppImage.

See, that's where you guys have problems. A lot of you philosophies are the opposite of the way things work on Linux. It's suggested that people use things such as software stores because there are people maintaining the software there that know how to check if it works well with the distro in question and if it's malicious or not.

Distributing AppImages without any sort of package manager kinda goes back to the Wild West ways of Windows where you have to go to some random website to download your applications.

[probonopd]

Exactly. We don't need package managers for AppImages. We want drag and drop like the Mac had in 1984.

[simoniz0r]

Yeah, but where do you get those packages? That's the problem. You don't have any sort of system setup for having an AppImage be distributed from a consistent source. You might not need a package manager for AppImages, but people sure would like to have one. Users have to go to a website and put their trust in the developers rather than being able to trust a relatively small group of people who evaluate packages to make sure that they work well and are not malicious.

Promoting something like AppImages being used on Linux is kind of the opposite of the standards Linux distros have established for providing packages that are in working order and not malicious. I can see why they'd be hesitant to add support for AppImages when y'all are so hesitant to add support for things that have been standard on Linux for quite some time.

Having a package manager for AppImages would do nothing but benefit you. You wouldn't have to change them so that they require the package manager; it would just make it easier for people to have a source to get AppImages from that they can trust. Doing that also makes you look much better to distro maintainers and such as they would have an easier way to test preapproved AppImages on their distros and/or with their software.

It's really a win-win situation for you, and I wish you'd take your personal views out of this, step back for a moment, and look at the big picture. Linux users aren't a bunch of crazy people who like package managers because that's all they know; we like using package managers because they're an easy way for us to get trustworthy software in a consistent manner.

What you're doing now with AppImageUpdate, etc is essentially doing half the work of a package manager anyways; I just don't understand why you're so unwilling to take the next step or at least be willing to help people in creating their own solutions.

What you've got going on with AppImageHub is a step in the right direction, but it fails to do many of the things that Linux users expect when getting a package from a distributor. AppImages are checked once, and then they're assumed to be good forever; that doesn't really provide anything for the user to go on. A system where the user submits each new release of an AppImage for review would be much better in the long run.

As it stands, an author could very easily do something to break their AppImage release after submission or just completely stop releasing AppImages, and their link would just stay in AppImageHub's list until someone maybe noticed. You say that tracking version numbers doesn't scale, but I honestly think you're going to find that not tracking releases at all is going to scale much worse as you potentially end up with a list of broken or nonexistent AppImages.

[TheAssassin]

As it stands, an author could very easily do something to break their AppImage release after submission or just completely stop releasing AppImages, and their link would just stay in AppImageHub's list until someone maybe noticed. You say that tracking version numbers doesn't scale, but I honestly think you're going to find that not tracking releases at all is going to scale much worse as you potentially end up with a list of broken or nonexistent AppImages

A pretty close-minded thinking. AppImageHub does (or will? CC @probonopd) perform "keepalive" checks, i.e. regularly check whether the application links are still working. No need to depend on a version number.

Also, there's so many versioning schemes you can't simply implement them all without adding more and more maintenance overhead.

[probonopd]

On-topic:

Desktop environments should handle "known" file formats better than pretending them to be "unknown". This is what this ticket is all about.

---

Off-topic:

__tl;dr:__ It is not a coincidence nor a bug that AppImages are very different from distribution packages. It is an intentional choice. If you disagree with this model, then maybe other software distribution models might be better suitable to your needs.

Yeah, but where do you get those packages?

From the upstream application developer's/vendor's website. For example, LibreOffice from https://libreoffice.org/download/appimage/.

You don't have any sort of system setup for having an AppImage be distributed from a consistent source.

Exactly - because we don't want a "consistent" source. We want to enable application authors to distribute applications directly to end users, without intermediaries.

Users have to go to a website and put their trust in the developers

Exactly. If you do not trust the author of an application, then it'd be better not to use that application in the first place.

rather than being able to trust a relatively small group of people who evaluate packages to make sure that they work well and are not malicious

You don't have that on Windows or the Mac either, at least apart from the Stores that the OS vendors have lately been trying to push on people.

Promoting something like AppImages being used on Linux is kind of the opposite of the standards Linux distros have established

Yes. The AppImage model is a "un-distro" model much closer to an .app inside a .dmg for Mac users, or a "portable application" in the Windows world.

Having a package manager for AppImages would do nothing but benefit you.

Users who like the traditional distribution model with package managers can use the package manager that coes with their distribution -- there is no need to replicate that experience with AppImage. For what they are intended to do, existing package mangers such as apt and rpm do their job rather well.

It's really a win-win situation for you, and I wish you'd take your personal views out of this, step back for a moment, and look at the big picture.

This whole project is funded by my "personal views". But hey, this is open source, so if you think you want a package mangager for AppImages then you can write one. I certainly won't.

Linux users aren't a bunch of crazy people who like package managers because that's all they know; we like using package managers because they're an easy way for us to get trustworthy software in a consistent manner.

Then - why don't you just use deb and rpm and be done with it? Does the Linux initially would be inferior to the existing, proven ones?

What you're doing now with AppImageUpdate, etc is essentially doing half the work of a package manager

No - it's an entirely decentral approach. The application author is in full control. It's conceptually much more like https://sparkle-project.org/ on the Mac.

What you've got going on with AppImageHub is a step in the right direction, but it fails to do many of the things that Linux users expect when getting a package from a distributor.

That's the point - we don't want to be the "distributor"; but more like a "phone book". The interaction model we are aiming for is a direct interaction between the user and the application author with no one in between. Take a company that wants to put the applciation download behind a registration page. With AppImage, they can. Example: https://ultimaker.com/en/products/ultimaker-cura-software - they are asking the user to full in a short questionnaire in return to giving away the software for free. Hard to do with a traditional package manager approach.

AppImages are checked once, and then they're assumed to be good forever; that doesn't really provide anything for the user to go on.

Indeed this is not much more than an initial check that the initial AppImage met a certain minimum set of standards and that the AppImage can work in principle; this is all we can do at the moment. We don't have the resources to ensure that every version of every application is "known good" all the time.

Also, we don't really want to hear about bugs in particular AppImages, those should be addressed to (and resolved by) the respective application authors directly. We don't even understand most of the software that people distribute in AppImages. We want to enable application authors to directly support their users, in the same way they already do for the other desktop OSes.

A system where the user submits each new release of an AppImage for review would be much better in the long run.

That would be more like a centralistic app store. Commercial app stores from the application vendors have large teams. The open source community based way would be, in contrast, to crowd-source tests, reviews, improvements, and ultimately, trust. Think "peer production" rather than "central team". I am happy to discuss ideas on how to make this happen.

[simoniz0r]

Unfortunately, your model does not work out for me at all. I will not be investing further time into AppImage.

I'm not the only one who feels like your tools are lacking either... Developers who use AppImage feel the same.

[TheAssassin]

Unfortunately, your model does not work out for me at all. I will not be investing further time into AppImage.

Contradictory to you continuously posting negative comments here.

By the way, random quote with unknown source without a date, what a great and reliable and _meaningful_ source...

[simoniz0r]

I don't really want to out the author. I posted a link in your IRC that has the author's name.

And if you don't expect me to make some sort of reply to that, you're silly...

[vadi2]

The author in the image has not educated themselves on the appimage daemon which handles updates - let them know about it :)

[simoniz0r]

They are aware; they are not happy with the way it works.

[TheAssassin]

appimage daemon which handles updates - let them know about it :)

There is no "auto update daemon", at least nothing official.

They are aware; they are not happy with the way it works.

That can certainly not be true, see above statement...

[simoniz0r]

(no, I'm not just pulling random quotes; this is all from a conversation about universal package types in the developer's Matrix channel)

[TheAssassin]

You just don't get it, @simoniz0r. Please, stop wasting your and our time, and go get happy with something else.

[simoniz0r]

I think y'all just don't get it hence why I'm not investing any more time here. You don't even have comments for that author's problems.

[TheAssassin]

Ah, shut up. You always refused to have a discussion, as you are unable to change your own mind. As soon as someone else is disagreeing with you, you become totally stubborn and it is impossible to continue a discussion, as you then start to "explain why you are right and your way is the only one true right correct way", instead of relying on facts, and convincing with arguments. You cite unreliable sources, you make wild claims without explanations or evidence, you make false accusations, etc. This is not how a discussion works.

You always say you "don't invest time any more". That's a lie. You still are trying to force everybody else to change their own opinions to fit your own. If they don't, they are the ones who are wrong, they don't understand the world, they ignore everybody else because you think you are the voice of the world. You really seem to believe that. You ignore that the majority of feedback regarding AppImage is the complete opposite of your statements. You're caught in some filter bubble which lets pass through only statements which agree with your own thinking.

You are yourself a close-minded person that can't tolerate different opinions. You don't understand what "free software" means: everybody's free to do whatever they want with the software, the author decides what to do with his own software, like you can choose to modify aspects by forking it. It is impossible to you that authors aren't waiting for some "messiah" who's going to explain them their own vision.

By the way, why reply to _you_ to the unknown author of questions on some random screenshot? That's a ridiculous expectation to begin with. We are not afraid to discuss anything with anybody. It's _your_ methods that we dislike. You're not a person that it is easy or fun to work with. I really tried to discuss with you, convince you with arguments, but it's simply not possible to have a factual discussion with you. At least not on the Internet.

@probonopd told you _more_ than once: AppImage is not made for you.

And let me finally tell you: we are glad we lost _you_ as a user. Saves us time for people who share our vision. We don't _need_ you as a user. Don't overestimate _your_ position in the project. You're a user, or have been, nothing else.

[simoniz0r]

I'm glad you're willing to make yourself look like that in public.

[vadi2]

@simoniz0r you're being toxic and harming the open-source community by attacking the people who are working to change it for the better (in ways they believe they are right).

[probonopd]

All, this discussion has gone well above what is appropriate in an issue tracker. Let’s consider that we are working on this in our free time, this project is supposed to be fun, it’s OK to disagree but not to attack.

I will consider moving my parts of this discussion to the discussion forum where it should have been in the first place, delete the rest and leave it up to each of you whether you want to participate in the discussion there (or not).

[probonopd]

This is being discussed for GNOME at https://gitlab.gnome.org/GNOME/nautilus/issues/443

António Fernandes has made a detailed and imho well thought-out proposal that strikes the right balance between usability and being cautious:

[probonopd]

Looks like Ubuntu has a policy to "protect the Ubuntu desktop from malware" that explicitly does not want this https://bugs.launchpad.net/ubuntu/+source/mime-support/+bug/688736. The result is not "protecting the Ubuntu desktop from malware" but making it "more cumbersome than needed to set the execute bit":

The error message when trying to open an executable file must:

explain why this may be a dangerous file
not give the option of launching it anyway

The error message when trying to open an executable file should:

give the option of looking for trusted software instead
link to a web page that has more details

https://wiki.ubuntu.com/Security/ExecutableBit reads like an anti-advertisement to the idea of application bundles distributed outside of Ubuntu:

Normally and preferably software should be installed using the Ubuntu Software Center which is the primary source of software in Ubuntu.

Files from outside the supported software repository are not marked as "executable" since they did not get installed via a trusted source. Because of this, attempting to open/run downloaded files that are software will fail. These files are blocked for security reasons to help unsuspecting users avoid malware (i.e. malicious software like trojan horses, worms, and viruses).

This is not acceptable, as users are discussing on

https://wiki.ubuntu.com/Security/ExecutableBit/comments

We disagree with this, since this degrades the usability of AppImages and other software that is downloaded outside of the distribution's channel. We need to propose something better. I think the Mozilla dialog shown above strikes a good balance between informing the user and not making things more cumbersome than needed.

[TheAssassin]

https://wiki.ubuntu.com/Security/ExecutableBit

I can confirm that this page is wrong. I spent a few hours explaining to a few people that the executable bit is not a security mechanism, at least not as long as the same user owns the file (and can change the permissions) or has read access and can copy the file to another directory and make it executable. Just because it's on the Internet it doesn't have to be true.

The comments you commented, well, it's not in Ubuntu's business interest to tell unexperienced users to use anything but ways of distribution they control, I'd say.

[simoniz0r]

This decision is coming from upstream, actually. Ubuntu is just going along with it.
See the commit where GNOME decided this was a good thing to do here.

[TheAssassin]

@simoniz0r you didn't get the point. This wiki page is from 2014. What does a commit from last week have to do with an almost 4 years old wrong wiki page?

[simoniz0r]

Everything. What you want is never going to happen now. Time to look for alternate solutions.

[TheAssassin]

https://gitlab.gnome.org/GNOME/nautilus/merge_requests/229

[probonopd]

Someone (not me) opened https://bugs.kde.org/show_bug.cgi?id=394672 for KDE