New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper handling of ELF files in desktop environments #374

Open
probonopd opened this Issue Apr 1, 2017 · 32 comments

Comments

Projects
None yet
5 participants
@probonopd
Member

probonopd commented Apr 1, 2017

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:

screenshot_20170401_222220

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

weajhyo

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

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Apr 16, 2017

Member

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

screenshot from 2017-04-16 11-45-46

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.

Member

probonopd commented Apr 16, 2017

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

screenshot from 2017-04-16 11-45-46

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

This comment has been minimized.

Show comment
Hide comment
@IGassmann

IGassmann Mar 21, 2018

Submitted ticket for KDE and Gnome.

IGassmann commented Mar 21, 2018

Submitted ticket for KDE and Gnome.

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Mar 21, 2018

Member

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

Member

TheAssassin commented Mar 21, 2018

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

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Mar 24, 2018

Member

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.

Member

probonopd commented Mar 24, 2018

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

This comment has been minimized.

Show comment
Hide comment
@IGassmann

IGassmann Mar 25, 2018

@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.

IGassmann commented Mar 25, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Mar 25, 2018

Member

@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.

Member

TheAssassin commented Mar 25, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Mar 25, 2018

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.

simoniz0r commented Mar 25, 2018

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

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Mar 25, 2018

Member

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

Member

probonopd commented Mar 25, 2018

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

@simoniz0r

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Mar 26, 2018

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.

simoniz0r commented Mar 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Mar 26, 2018

Member

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.

Member

TheAssassin commented Mar 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Apr 26, 2018

Member

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.

Member

probonopd commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

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.

appimage

simoniz0r commented Apr 26, 2018

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.

appimage

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Apr 26, 2018

Member

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...

Member

TheAssassin commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

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...

simoniz0r commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@vadi2

vadi2 Apr 26, 2018

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

vadi2 commented Apr 26, 2018

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

@simoniz0r

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

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

simoniz0r commented Apr 26, 2018

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

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Apr 26, 2018

Member

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...

Member

TheAssassin commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

appimage

appimage

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

simoniz0r commented Apr 26, 2018

appimage

appimage

(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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Apr 26, 2018

Member

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

Member

TheAssassin commented Apr 26, 2018

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

@simoniz0r

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

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.

simoniz0r commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Apr 26, 2018

Member

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.

Member

TheAssassin commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r Apr 26, 2018

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

simoniz0r commented Apr 26, 2018

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

@vadi2

This comment has been minimized.

Show comment
Hide comment
@vadi2

vadi2 Apr 26, 2018

@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).

vadi2 commented Apr 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Apr 26, 2018

Member

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).

Member

probonopd commented Apr 26, 2018

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 comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd May 18, 2018

Member

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:

Member

probonopd commented May 18, 2018

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

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd May 20, 2018

Member

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.

Member

probonopd commented May 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin May 20, 2018

Member

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.

Member

TheAssassin commented May 20, 2018

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 comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r May 20, 2018

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.

simoniz0r commented May 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin May 20, 2018

Member

@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?

Member

TheAssassin commented May 20, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@simoniz0r

simoniz0r May 20, 2018

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

simoniz0r commented May 20, 2018

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

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd May 26, 2018

Member

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

Member

probonopd commented May 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment