Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proper handling of ELF files in desktop environments #374
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.
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:
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.
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
This was referenced
Mar 18, 2018
In the GNOME ticket, someone writes
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.
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.
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.
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.
Desktop environments should handle "known" file formats better than pretending them to be "unknown". This is what this ticket is all about.
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.
From the upstream application developer's/vendor's website. For example, LibreOffice from https://libreoffice.org/download/appimage/.
Exactly - because we don't want a "consistent" source. We want to enable application authors to distribute applications directly to end users, without intermediaries.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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...
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.
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).
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:
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":
https://wiki.ubuntu.com/Security/ExecutableBit reads like an anti-advertisement to the idea of application bundles distributed outside of Ubuntu:
This is not acceptable, as users are discussing on
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.
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.
This decision is coming from upstream, actually. Ubuntu is just going along with it.