Desktop Entry Specification is missing [ as a reserved character in Exec

[meator]

On 6/25/24 18:13, Bollinger, John wrote:
>  > I have also messaged this mailing list about this
>  > (See "A few questions about escaping in desktop files" sent in 22.
>  > August 2022). In this thread, I was assured that the implementation can
>  > either choose to do word splitting and unquoting itself or it can pass
>  > the job to a shell.
> 
> I do not find that surprising, but the spec really ought to be clear 
> about it.

I should note that the answers I got on that mailing list thread were 
from people (I assume) not directly affiliated with XDG. Simon McVittie 
has stated that he didn't write the spec. So all of this is still 
speculation I believe. But I found the arguments made on that thread 
reasonable.

I have reread the thread (it has been two years since I've discussed 
this). Here's a link if you're curious: 
https://lists.freedesktop.org/archives/xdg/2022-August/014620.html

The argument made is that there already exist two major implementations 
handling the Exec key either way. This means that both the shell 
approach and the manual approach "are correct", because if they aren't, 
it would make a major implementation not compliant, which would make the 
specification less reliable and it would anger other implementers too. 
Many specifications follow a "no backwards-incompatible changes" out of 
necessity. I assume that the Desktop Entry Specification would not 
accept forbidding one of these approaches for this reason either.

> And it should present the quoting rules as a consequence of that freedom,
> not standalone requirements. That would have mooted the present discussion,
> and if implemented, it might yet moot some future ones. Something like this,
> for example:
> 
> ---
> 
> [spec draft] >
> ---

I +1 your efforts. It would be nice to see clarification in the 
specification. You also impose stricter rules on quoting which would 
make passing the arguments to the shell feasible. This would remove 
behavior discrepancies between the shell approach and the manual approach.

One disadvantage I see is that the entire shell quoting mechanism has to 
be specified here. Shell is not directly related to desktop files. 
Implementations choosing to handle the Exec key manually will not even 
involve a shell altogether. This imposes a pretty hard artificial 
dependency on the /bin/sh quoting mechanism.

In an ideal world, this would be solved by determining the manual word 
splitting and unquoting method as the only valid one. This would get rid 
of half of the unquoting rules, "reserved characters" would simply go 
away and the Exec line would be cleaner and easier to read/write by 
humans. But that will not happen because of the reasons outlined in this 
thread.

>  > [...]  the
>  > [ character is missing from the reserved characters, which means that
>  > all implementations using the shell for execution very likely result in
>  > unintended behavior for desktop files which contain [ in an unquoted
>  > argument of Exec.
> 
> Possibly. [ itself is a standard external command, equivalent to "test".
> It is used frequently for that purpose in shell conditional commands.  And
> even when not appearing as a command name, unquoted [ still represents
> itself unless paired with a matching ].  I speculate that that may 
> explain why
> [ is not on the must-be-quoted list.  But that would be another good reason
> for being more explicit about how the Exec key can be used, and to discuss
> quoting in that context, instead of as standalone requirements.

This could be of concern, but the main issue I've outlined in the 
originating e-mail of this thread is globbing. Implementations using the 
shell for handling of Exec will treat the following line:

 > Exec=/usr/bin/xte[r]m

as /usr/bin/xterm (if xterm is installed on the system in the expected 
location). This is true unless these implementations employ special code 
for [, which is not likely, because it is not specified.

Implementations doing word splitting and unquoting manually will see 
/usr/bin/xte[r]m, which is arguably the correct behavior.

If the desktop file should choose to invoke [ (as in /usr/bin/[), I 
believe that no special treatment is necessary.

I would also like to point out that "real" desktop files used in 
production will never contain these special edge-cases were discussing. 
This discussion is mostly theoretical. I don't think that there could be 
a legitimately useful desktop app which would use /usr/bin/[ as its main 
executable. "Real" desktop files will also not likely contain [, ], { or 
} and if they would contain these characters, they might already be 
quoted out of caution or because the argument containing these 
characters already contains one of the reserved characters which require 
the entire argument to be quoted.

But still, the specification should be clear. There is currently no way 
to do perfect forwarding of a commandline to a desktop file portably 
when strictly following the specification, which could be a security 
concern if the commandline is user supplied.

Because of this thread and because of other concerns, I chose to switch 
the Exec handling mechanism of j4-dmenu-desktop (a desktop file runner 
program I maintain) from the shell approach to the manual one.

Thanks, meator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1A14CB3464CBE5BF.asc
Type: application/pgp-keys
Size: 6275 bytes
Desc: OpenPGP public key
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240625/5c7f8131/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240625/5c7f8131/attachment.sig>