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 representsitself 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]mas /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
OpenPGP_0x1A14CB3464CBE5BF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
