+1 for removing the ability to launch .desktop files but retaining ability to launch binaries and scripts.

It even looks like in version 5.33 of the file utility PIE executables are now identified as such, resolving
one of the original issues that prompted reconsideration of supporting binary launching from nautilus.
This means there will no longer be an impetus for FireFox to distribute non-PIE executables, so they
can be more secure in their binary distribution for linux (the inability to launch PIE executables from
linux file managers has been a problem for them).

Removing the ability to launch .desktop files resolves the CVE fairly definitively, and people seem to be
much less concerned about their removal. Not many people are actually launching apps from the desktop
it seems, they're using the DE launchers as intended, but many people seem to not necessarily want their
random dev scripts, some isolated/portable apps and meticulously sorted folders full of games integrated
with the system.

Nautilus doesn't need to change to support the PIE executables (other than rolling back this recent change)
as far as I can tell. It looks like 'file' has changed to report both shared objects and executables as executables
if they are PIE. While Nautilus may wish to inspect the 'interpreter' flag (once libmagic adds support for
exposing this, not clear if they have yet but as indicated here they will in due course) to decide whether an
ELF is intended to be executed or linked, I don't really see a problem if it doesn't and if it just executes them
all if they have the execute bit set (and the user confirms they want to execute). They're valid executables
that can be executed from the command line with ./libfoo.so, they just usually segfault is all (but some don't
and print things to stdout - not super useful without a terminal, but also harmless). Nonetheless if Nautilus
thinks shared objects are executables until libmagic exposes the relevant flags for it to check, that's
not so bad in the interim.

If the ability to launch executables remains removed entirely, distros and some savvy users will create a
launcher program and associate executable formats with it. But this may not be ideal for scripts, since
each type will need to be associated separately - the non-executable ones with your text editor and the
executable ones with both the text editor and some 'run' or 'run in terminal' launcher programs. It's also
not clear to me whether the presence of the executable bit counts as a different file format for the purpose
of setting file associations via nautilus. If it doesn't, then one would have the 'run' option with such a
custom launcher even if the executable bit is not set. The launcher program, if well designed, would give a
GUI error about the execute bit not being set. This situation is actually not so bad, though it a) defeats
the purpose of removing executable launching support if distros will just work around it in this way and
b) does not allow the current situation where you get a popup asking "open, or run?", which is something
I quite like - since you often switch between both with executables and it is easy to forget to right click
and select 'open with'. A confirmation generally is good for preventing accidentally running potentially
malicious executables too.

One final possibility might be if Nautilus allowed associating multiple programs with a mime type,
without a default, such that it asks every time which program to use. That way distros could have a
'run' and 'run in terminal' launcher program associated with executable file types as well as the
usual program. This is not ideal however, because if it's part of the user-exposed file associations,
the user could change it accidentally (setting their game to always open with 'run program' and
inadvertently making this the setting for all executables), opening themselves up to accidentally
executing things. Probably better that Nautilus continue to treat executables as special.

All things considered, given that the feature (except for .desktop files) is popular enough to be
worked around, and given that the workarounds are more likely to result in accidental execution
than if Nautilus treats executables as special, it seems like the feature to run executables from a
file browser, if it exists at all (which it is too popular not to IMHO), belongs in Nautilus. The
PIE problem is mostly resolved and will likely become fully resolved in time (distinguishing
between shared objects and PIE executables with the 'interpreter' flag), and the CVE with .desktop
files gone.

Hi All,

We have just updated the version 6.4.0 for linux ( it will display 6.4.0/20190118 in options/about ). This time it should work on many distributions, as long as the glibc is not too old. The problem was that we have switched to statically linking libstdc++ (in order to improve compatibility with older distributions), but it is not trivial and requires a linker script to take care of a few weak symbols.

Hello Soel,

hard to say, if the Error is cause or effect. Would be interesting, if other users see the same error starting Pianoteq Stage from commandline.

Maybe I'm just not affected because of using Pianoteq v6.4.0 Standard and not Stage.