After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737849 - Can't launch position independent executables
Can't launch position independent executables
Status: RESOLVED NOTGNOME
Product: nautilus
Classification: Core
Component: File and Folder Operations
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 741183 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-10-03 15:54 UTC by Mike Hommey
Modified: 2018-07-15 13:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mike Hommey 2014-10-03 15:54:50 UTC
Take the following:

$ echo "int main() { return 0; }" > foo.c
$ gcc -o foo foo.c -fPIE -pie
$ file foo
foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=2c65c1c5fa4182783066b29fca5a7362eb95c325, not stripped

Now, open the directory containing foo in nautilus. If you get the properties of foo, it will tell you it's an application/x-sharedlib, which matches the file output. Except really, it's an executable. It just happens that at the ELF level, position independent executables are... shared libraries.

Now, try to open that executable like any other executable. It fails, saying:
  Could not display "foo"
  There is no application installed for "shared library" files

This essentially prevents software vendors shipping applications with position independent executables. Can't use .desktop files to get around this, and I'm not aware of anything else that could help. (I found some App Bundle proposals, but that doesn't seem to have gone anywhere).
Comment 1 Matthias Clasen 2014-10-03 23:02:26 UTC
nautilus is not an application launcher, really. But using a desktop file to launch your app works just fine here; using both gtk-launch or nautilus. What problem are you seeing with that ?
Comment 2 Mike Hommey 2014-10-04 00:08:44 UTC
Using a desktop file doesn't work.

If you put the executable name in the Exec field without a path, launching it fails with:
    There was an error launching the application.

If you put the executable name in the Exec field prefixed with "./", launching it works if and only if the nautilus process's cwd is the directory containing the .desktop file. Otherwise, same error as above.

Obviously, you can't put an absolute path in a .desktop file you ship in a tarball.

So what do you suggest Mozilla and other software vendors do? Tell users to download a tarball, unpack it, add the unpacked directory in $PATH and run the .desktop file?
Or do you suggest software vendors create installers? Or that they provide distro packages?

The thing is, users can currently download a tarball, unpack it, and run firefox just fine... a *lot* of desktop linux users do that instead of using the packages in their distro. There must be a reason for that. But that doesn't work if firefox is PIE.
Comment 3 Daniel Micay 2014-10-04 19:51:02 UTC
> There must be a reason for that.

Distributions with an old version of Firefox in their repositories missing lots of features and most of the bug fixes due to 'stable' releases.

> This essentially prevents software vendors shipping applications with position
independent executables.

Chrome has been a position independent executable for years and so is Steam. Chrome is shipped as a deb package for Ubuntu/Debian-based distributions and an rpm for OpenSUSE/Fedora. It needs to install the chrome-sandbox binary as setuid in order to enter the chroot and namespaces implementing the first layer of the renderer sandbox so it's a requirement for other reasons.

Chromium is a better option if the distribution is rolling or at least has rolling applications with a frozen core but many users are stuck with that and use the Chrome package.

> Or do you suggest software vendors create installers? Or that they provide distro packages?

How about shipping a wrapper script for this use case but never actually installing it? The Tor project ships a start-tor-browser script as a wrapper around a position independent build of their Firefox fork.

GNOME could deal with this via deeper inspection of shared objects rather than just whatever it's doing now (libmagic?).
Comment 4 Matthias Clasen 2014-10-05 16:25:18 UTC
(In reply to comment #2)

> So what do you suggest Mozilla and other software vendors do? 

I'm not suggesting anything. I'm merely trying to understand the complaint well enough to figure out where to move this bug.
Comment 5 Daniel Micay 2014-12-06 03:00:44 UTC
IMO, Nautilus should just completely drop support for executing raw binaries in favour of desktop files. Most executables aren't GUI applications and running them directly doesn't make sense.

Desktop files work well for launching both Console (like htop) / GUI applications from Nautilus, and provide a much better user experience as having an icon, i18n, and more is supported. If any half-baked / redundant feature deserves to be dropped, it's this one. You'll be doing users a huge favour by zapping the latest dumb excuse to be leaving ASLR disabled in 2014.
Comment 6 Mike Hommey 2014-12-06 09:07:40 UTC
(In reply to comment #5)
> IMO, Nautilus should just completely drop support for executing raw binaries in
> favour of desktop files.

Desktop files don't work for things that aren't in $PATH.
Comment 7 Daniel Micay 2014-12-06 16:35:58 UTC
Directly using relative paths isn't portable (some file managers support it) but you can use dirname on %k to accomplish the same thing.
Comment 8 André Klapper 2014-12-08 19:49:15 UTC
*** Bug 741183 has been marked as a duplicate of this bug. ***
Comment 9 Hanno Böck 2014-12-08 20:29:28 UTC
This is essentially not a bug in nautilus, but in file/libmagic. I reported it there and I think it should be fixed there (while that's not completely trivial):
http://bugs.gw.com/view.php?id=404

(for the record: Dolphin/Konqueror are affected by exactly the same issue)
Comment 10 Yann Droneaud 2016-05-12 16:20:58 UTC
(In reply to Hanno Boeck from comment #9)
> This is essentially not a bug in nautilus, but in file/libmagic. I reported
> it there and I think it should be fixed there (while that's not completely
> trivial):
> http://bugs.gw.com/view.php?id=404
>

Sure, file / libmagic [1] should report PIE as executable file too,
but nautilus' issue is not directly related to those tool / library:
nautilus is using GIO which is part of GLib.

See:

  in https://developer.gnome.org/gio/stable/GFileInfo.html
  - g_file_info_get_content_type()
  - G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE
  - G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE

  in https://developer.gnome.org/gio/stable/gio-GContentType.html
  - g_content_type_guess()
  - g_content_type_can_be_executable()

It happens those functions rely on a copy [2] of the reference implementation library [3] for shared MIME database specification [4] and use shared MIME info database [5][6].

> (for the record: Dolphin/Konqueror are affected by exactly the same issue)

I think those are using the same code / database as Glib/GIO.

Perhaps a bug should be opened @ XDG / freedesktop too ...

[1]  http://www.darwinsys.com/file/
[2]  https://git.gnome.org/browse/glib/tree/gio/xdgmime?h=glib-2-48
[3]  https://cgit.freedesktop.org/xdg/xdgmime/
[4]  https://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/
[5]  https://www.freedesktop.org/wiki/Software/shared-mime-info/
[6]  https://cgit.freedesktop.org/xdg/shared-mime-info/
Comment 11 David Faure 2017-01-14 10:30:57 UTC
The upstream shared-mime-info bug report for this is https://bugs.freedesktop.org/show_bug.cgi?id=97226

If anyone knows how to distinguish a shared lib from a PIE executable, please say so in that freedesktop bug report, and I'll implement it.
Comment 12 António Fernandes 2017-08-15 08:39:09 UTC
(In reply to David Faure from comment #11)
Thanks for taking the time to report this upstread, David. We can close this nautilus report for now.
Comment 13 Hanno Böck 2017-08-21 10:05:10 UTC
Actually if you look at the "upstream" bug (not the one at freedesktop, the one at libmagic) you'll see that its author thinks it's not his responsibility to fix this either. So we have a situation of several projects pointing fingers at each other that the other one should fix something.

In the meantime major distributions have decided to move ahead and enable -pie, so right now it simply means nautilus can no longer run executables by clicking on them. I wonder if the whole functionality of running executables from a filemanager shouldn't be discouraged anyway, as it is an obvious attack vector (mostly on windows, but the issue is identical for all desktops).
Comment 14 António Fernandes 2017-08-21 10:59:11 UTC
(In reply to Hanno Boeck from comment #13)
> In the meantime major distributions have decided to move ahead and enable
> -pie, so right now it simply means nautilus can no longer run executables by
> clicking on them. I wonder if the whole functionality of running executables
> from a filemanager shouldn't be discouraged anyway, as it is an obvious
> attack vector (mostly on windows, but the issue is identical for all
> desktops).

That's right, as per comment 1, nautilus is not an application launcher. Even then, the safe and recommended way to launch GUI applications is standardized in the form of *.desktop files.

I'm not sure what problem PIE are trying to fix, but it seems like bundling technologies (flatpak, snap, etc.) offer a more flexible and both user- and vendor-friendly way to distribute software.
Comment 15 Daniel Micay 2017-08-21 15:15:41 UTC
> I'm not sure what problem PIE are trying to fix

PIE is an important security feature. It enables full Address Space Layout Randomization, which has been an industry standard security feature for years. GNOME should be offering the same experience for ET_EXEC (non-PIE) and ET_DYN (PIE) executables, otherwise it's holding back adoption of a security feature as it has done with Mozilla's Firefox builds.
Comment 16 André Klapper 2017-08-21 16:18:28 UTC
António: https://fedoraproject.org/wiki/Packaging:Guidelines#PIE and https://fedoraproject.org/wiki/Changes/Harden_All_Packages might provide some actual technical background.
Comment 17 Daniel Micay 2017-08-21 16:27:39 UTC
Not supporting launching executables directly would be perfectly fine if it was done consistently instead of supporting it for executables without ASLR support but not those with ASLR support. Most executables will end up being PIE now that it's the default on most major distributions so executables that can still be run like this will be an edge case. Should decide whether or not launching executables should work and either remove it or make it work properly rather than doing nothing which holds back desktop Linux security.
Comment 18 António Fernandes 2017-08-21 16:44:09 UTC
(In reply to Daniel Micay from comment #15)
Thank you so much for the clear explanation. We really need to make it more clear that the file browser is not to be relied on as an application launcher.

I don't know if removing support for running non-PIE for consistency is the right way to do it.
Comment 19 Hanno Böck 2017-08-21 16:47:40 UTC
> I don't know if removing support for running non-PIE for consistency is the right way to do it.

I think it absolutely is.

Right now you have the following situation: Nautilus will run some executables, but not the ones created by modern linux distributions. Thus likely if a user clicks on an executable it will simply not work.

However if an attacker wants to trick a user into clicking on a malicious executable he can just compile that one without pie (he's an attacker, so he doesn't care if his malware doesn't have security features).

Thus right now you have the worst of both worlds: A feature that usually doesn't work in the normal use case, but can be made to work if an attacker is trying to abuse it.
Comment 20 António Fernandes 2017-08-21 17:00:20 UTC
For what is worth, I actually agree with comment 19 and don't see any need to launch applications from the file browser. Just worried about the usual negative impact of removing a (mis)feature. But when it must be done, it's done. But this is going a bit off-topic, I am sorry.
Comment 21 Carlos Soriano 2017-08-21 17:03:02 UTC
We cannot remove launching apps from the file browser as long as Nautilus handles the desktop.

Once we remove the desktop handling, we can reconsider this.
Comment 22 Daniel Micay 2017-08-21 17:06:16 UTC
It wouldn't be removing support for launching apps, only legacy executables. All major distributions are defaulting to generating PIE executables so choosing not to work around libmagic classifying them as shared objects was already a decision to not support launching executables from Nautilus, other than legacy ones compiled in the past.
Comment 23 Carlos Soriano 2017-08-21 17:12:51 UTC
Doesn't make sense to remove the support for raw executables and still allow desktop files, because they have effectively the same power.

And desktop files are a very important feature of the desktop handling of Nautilus.
Comment 24 Daniel Micay 2017-08-21 17:20:07 UTC
There isn't support for launching raw executables unless they were compiled before distributions switched to enabling PIE by default. The issue was about making PIE and non-PIE consistent so projects like Firefox don't hold off on adopting ASLR due to Nautilus. It can be resolved by making it possible to launch executables with ASLR support rather than removing support for launching executables without ASLR support.
Comment 25 Daniel Micay 2017-08-21 17:20:24 UTC
There isn't support for launching raw executables unless they were compiled before distributions switched to enabling PIE by default. The issue was about making PIE and non-PIE consistent so projects like Firefox don't hold off on adopting ASLR due to Nautilus. It can be resolved by making it possible to launch executables with ASLR support rather than removing support for launching executables without ASLR support.
Comment 26 Daniel Micay 2017-08-21 17:24:34 UTC
And it *is* already possible to tell apart a library without an entry point from a library with an entry point or a position independent executable.

Library:

/usr/lib/libQt5Concurrent.so.5.9.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=157c6e7cb027c3039e9785999e28956477df3b44, stripped


PIE:

/usr/bin/chromium: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6db5ffe5c4d82f39b42c90fc5cab54c015f8850f, stripped

Library that can be run as an executable:

/usr/lib/libc-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /usr/lib/ld-linux-x86-64.so.2, BuildID[sha1]=599894f097519996b776d6daef9dd26756e02a95, for GNU/Linux 2.6.32, not stripped

If a shared object has an interpreter set, it can be run, so Nautilus could be using that to distinguish between them. I'm not sure it ever made sense to do it this way via libmagic but if it is going to be done like this it should be done properly so it works with PIE.
Comment 27 Carlos Soriano 2017-08-21 17:29:23 UTC
Sure. Just comenting about the possibility of removing raw executables support from Nautilus.

Regarding the topic of the bug report, it was already fine as set by Antonio, Nautilus have nothing to do here since it's the lower libraries that tell us what to execute or not. So this is either glib or libmagic.
Comment 28 Daniel Micay 2017-08-21 17:36:35 UTC
libmagic does show that a PIE has an interpreter set, just as it does for a library like glibc which has an entry point and can be executed.

% /usr/lib/libc-2.25.so
GNU C Library (GNU libc) stable release version 2.25, by Roland McGrath et al.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.1.1 20170630.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.archlinux.org/>.
Comment 29 Carlos Soriano 2017-08-21 17:39:38 UTC
I understand.

This is not for Nautilus though, I'm afraid this discussion you are putting so much effort on here will end up nowhere if it's not moved where it belongs.

So my advice is to file a bug on those lower level libraries, and do a summarize of the points discussed here.
Comment 30 Yann Droneaud 2017-08-21 20:46:26 UTC
(In reply to Daniel Micay from comment #26)
> And it *is* already possible to tell apart a library without an entry point
> from a library with an entry point or a position independent executable.
>

Unfortunately, it's not possible ...

> Library:
> 
> /usr/lib/libQt5Concurrent.so.5.9.1: ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), dynamically linked,
> BuildID[sha1]=157c6e7cb027c3039e9785999e28956477df3b44, stripped
> 
> 
> PIE:
> 
> /usr/bin/chromium: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
> 2.6.32, BuildID[sha1]=6db5ffe5c4d82f39b42c90fc5cab54c015f8850f, stripped
> 
> Library that can be run as an executable:
> 
> /usr/lib/libc-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1
> (GNU/Linux), dynamically linked, interpreter /usr/lib/ld-linux-x86-64.so.2,
> BuildID[sha1]=599894f097519996b776d6daef9dd26756e02a95, for GNU/Linux
> 2.6.32, not stripped
> 
> If a shared object has an interpreter set, it can be run, so Nautilus could
> be using that to distinguish between them. I'm not sure it ever made sense
> to do it this way via libmagic but if it is going to be done like this it
> should be done properly so it works with PIE.

As I've explained, perhaps too briefly, in https://bugs.freedesktop.org/show_bug.cgi?id=97226#c4, and, more thoroughly, in https://bugzilla.redhat.com/show_bug.cgi?id=1296868 (see comments 4 and 6), having an interpreter is not required for a library to be "runable" by the kernel.

Here's the counter example:

$ file /lib64/ld-2.25.so 
/lib64/ld-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ec4a86e0f8eabd67f229ea367fdf26288c5d4fea, not stripped

$ /lib64/ld-2.25.so
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
[...]
  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
			object we can handle
[...]

(for the record ld.so is the program underlying ldd tool).

Anyway, most recents comments here mention file and libmagic, but Nautilus rely on xdg-mime / shared MIME info through GIO/Glib (see comment #10) to guess file type.

AFAIK the shared MIME info data base probe for magic values at fixed offsets in file to guess its content.

Hence, looking for an interpreter requires searching for a program header with p_type equal to PT_INTERP, and that cannot be described in the shared MIME info database XML source.
Comment 31 Michael Catanzaro 2017-08-21 21:53:11 UTC
After reading this bug, writing an annoyed comment, and deleting it, I will just say this: continuing to support launching non-PIE executables seems to be providing zero benefit to GNOME users right now, as all distribution-provided applications already use PIE and are thus unlaunchable. And it's clearly contributing to a very major security problem if Firefox considers that a sufficient reason to build without PIE support. It sounds like this feature cannot be fixed in the near future, so it should be removed.
Comment 32 Mike Hommey 2017-08-21 22:08:25 UTC
If nautilus can't run executables at all, how are users that download Firefox from mozilla.org and unpack it with nautilus are supposed to start it?
Comment 33 Mike Hommey 2017-08-21 22:09:50 UTC
(And .desktop files are not an answer, see comment 2)
Comment 34 Michael Catanzaro 2017-08-21 22:18:52 UTC
(In reply to Mike Hommey from comment #32)
> If nautilus can't run executables at all, how are users that download
> Firefox from mozilla.org and unpack it with nautilus are supposed to start
> it?

I've never heard of this problem before, because I've never seen a well-respected application attempt to ship a precompiled binary in a tarball before. This is genuinely surprising to me. I expect it is a very, very small problem for Firefox, because I have no doubt that well over 99% of Firefox's Linux users just use the Firefox provided by their operating system (which is safer as it's compiled with PIE).

One good option is to ship a flatpakref. That's the only supported mechanism for distributing third-party software in GNOME. It will avoid this problem. Alternatively you should ship RPMs and .debs like everyone else does.
Comment 35 Michael Catanzaro 2017-08-21 22:21:11 UTC
I'm also really, really surprised that Firefox considers the lack of support for launching PIE executables in nautilus to be a valid reason for leaving an essential security feature disabled. Or that running Firefox from the user's home directory is considered acceptable.

I would not expect users to be able to figure out how to launch your application if it doesn't install a desktop file anyway. Most likely, users will have no clue that nautilus supports launching executables. It's news to me.
Comment 36 Mike Hommey 2017-08-21 22:27:23 UTC
> I've never heard of this problem before

Hum, this is literally spelled out in comment 0 and 2.

> because I've never seen a well-respected application attempt to ship a precompiled binary in a tarball before

Firefox has *always* been shipped that way. And before that, Firebird, Phoenix, Mozilla Suite, Netscape Communicator and Netscape Browser. This goes back more than 20 years. Not a lot of applications are shipping precompiled binaries, and of the ones that do, few of them are actually GUI applications. And for something as big as Firefox, that was about the only reasonable way (apart from distros).

> I have no doubt that well over 99% of Firefox's Linux users just use the Firefox provided by their operating system

You would be surprised.

> One good option is to ship a flatpakref. That's the only supported mechanism for distributing third-party software in GNOME.

Note that this barely existed when I filed this bug.
Comment 37 Carlos Soriano 2017-08-23 07:02:15 UTC
(In reply to Michael Catanzaro from comment #31)
> After reading this bug, writing an annoyed comment, and deleting it, I will

Annoyed about what?

> just say this: continuing to support launching non-PIE executables seems to
> be providing zero benefit to GNOME users right now, as all
> distribution-provided applications already use PIE and are thus

Downloaded executables from internet are still used.

> unlaunchable. And it's clearly contributing to a very major security problem
> if Firefox considers that a sufficient reason to build without PIE support.
> It sounds like this feature cannot be fixed in the near future, so it should
> be removed.

Which feature cannot be fixed? Launching PIE executables? I think the bug report is precisely that they cannot be launched, we don't have specific code for launch these types of applications.
Comment 38 Danfun360 2017-09-04 16:45:38 UTC
I don't understand why many of you want to remove the ability to run raw executables from linux file browsers. To me such a removal would be a major regression in functionality. Not to mention that I don't like the idea of creating a .desktop file by hand for software that doesn't compile with one, especially if I compile that software frequently.
Comment 39 Daniel Micay 2017-09-04 16:47:59 UTC
It is effectively removed, by not implementing PIE support, since PIE is now the default nearly everywhere so only executables compiled in the past can be run this way.
Comment 40 Daniel Kahn Gillmor 2017-09-06 21:30:25 UTC
I note that this bug is marked "RESOLVED NOTGNOME" despite the fact that GNOME appears to contain a copy of shared-mime-info, as noted in comment #10.  

even if https://bugs.freedesktop.org/show_bug.cgi?id=97226 is resolved upstream, it won't be fixed in GNOME without a re-import of that library, right?
Comment 41 Daniel Kahn Gillmor 2017-09-06 22:19:13 UTC
Over on https://bugs.freedesktop.org/show_bug.cgi?id=97226 , 
Bastien Nocera seems to suggest that it will not be fixed in shared-mime-info, so:

> If you have applications that require this deep level of
> knowledge of the different formats, you'll probably want
> to use something more precise than the shared-mime spec.
Comment 42 Michael Catanzaro 2017-09-06 22:50:48 UTC
(In reply to Daniel Kahn Gillmor from comment #40)
> I note that this bug is marked "RESOLVED NOTGNOME" despite the fact that
> GNOME appears to contain a copy of shared-mime-info, as noted in comment
> #10.

No, shared-mime-info is used as a shared library. GLib contains a copy of xdgmime (as does WebKit). Unfortunately it is actually ahead of upstream xdgmime, which is unmaintained.
Comment 43 Carlos Soriano 2017-09-07 06:47:55 UTC
(In reply to Daniel Kahn Gillmor from comment #40)
> I note that this bug is marked "RESOLVED NOTGNOME" despite the fact that
> GNOME appears to contain a copy of shared-mime-info, as noted in comment
> #10.  
> 
I cannot see that statement in comment #10, neither it's true anyway. GNOME doesn't ship a copy of shared-mime-info.
Comment 44 Daniel Kahn Gillmor 2017-09-07 14:18:46 UTC
Apologies for all the confusion here.  I'm just looking to solve the original problem, which is that non-PIE executables are launchable from nautilus, and PIE executables are not.

Where specifically should the problem be solved?  Is there an open bug report about it that we should refer to as the canonical location?
Comment 45 gQuigs 2017-09-07 14:44:28 UTC
Can I take this back a sec and look at it from a design side: 
What is the ideal for what happens when a user clicks to open a executable in nautilus?

Currently when opening a desktop file it gives the option of Trust and Launch for me - that isn't planned on being dropped or is it?   

When clicking on a executable could we give them a similar prompt:
 * If a desktop file already exists for the binary we give them a warning that this is not the recommenced way to open an application.
 * If a desktop file doesn't exist for that binary we provide a similar trust warning and give them the option to autogenerate a desktop file for just themselves.  Once complete we mention that it will now show up in their menu.
Comment 46 Matthias Clasen 2017-09-07 20:37:51 UTC
(In reply to gQuigs from comment #45)

> When clicking on a executable could we give them a similar prompt:
>  * If a desktop file already exists for the binary we give them a warning
> that this is not the recommenced way to open an application.
>  * If a desktop file doesn't exist for that binary we provide a similar
> trust warning and give them the option to autogenerate a desktop file for
> just themselves.  Once complete we mention that it will now show up in their
> menu.

If desktop files could simply be autogenerated from binaries, there would be no need for them in the first place. Desktop files need to be shipped with the application, since they need to associate data (display name, icon, etc) with the executable that is otherwise not available.
Comment 47 Daniel Kahn Gillmor 2017-09-07 21:10:16 UTC
Comment #2 explains why it's infeasible to ship a .desktop file inside a tarball that contains the binary.
Comment 48 yury dubinsky 2018-01-05 17:04:39 UTC
Let’s say I am developing a GTK+ application and, from million of reasons, I have dozens of compiled variants of my program. Should I create .desktop file or a shell script to execute each variant? I am too lazy. I would open CLI. We can do everything in CLI. Thousands of people are pretty happy with CLI via SSH. Let’s drop Nautilus at all!  LOL!
I am very comfortable with CLI, but, in fact, when I need to execute compiled programs frequently I am still using GUI. Just switching to Nemo or Dolphin.
Current Dolphin executes file that are  “ELF 64-bit LSB executable” or “ELF 64-bit LSB shared object”, if the file has “execute” mode.
Nemo is more sophisticated. Nemo executes file that are “ELF 64-bit LSB executable”. But, if the file is “ELF 64-bit LSB shared object” Nemo prompts  “Make executable and run” or “Choose a program.” No difference what the file mode is. 

Just few extra comments. 
“Nautilus should just completely drop support for executing raw binaries in favour of desktop files” 
Why? A security concern? Add a confirmation prompt before executing and it will protect against accidental clicks.
“Desktop files need to be shipped with the application” 
Why?  If you are my friend and I am sending you an executable, why should I care about  a desktop file or another dummy one-word shell script just preserving an option to start from a File Manager?
Comment 49 Anonymous 2018-07-14 22:46:46 UTC
As this bug report receives additional traffic from people trying to figure out what happend in the mind of the nautilus developers when they decided to drop support for launching binaries, I'd just like to mention that I discovered a bugfix for this issue back when Nautilus introduced a similar bug.

When Nautilus suddenly lost the ability to select a file or folder by typing its name, I discovered that you can remove it and instead install Thunar.
Meanwhile I use pcmanfm-qt on gentoo which also works great.
Comment 50 Anonymous 2018-07-14 22:47:41 UTC
s/Meanwhile/By now/
Comment 51 André Klapper 2018-07-15 13:25:53 UTC
gnomebugtracker@dma.in-ulm.de:  https://wiki.gnome.org/Foundation/CodeOfConduct explains what is welcome here. Thanks for keeping this a respectful place.