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

[Bollinger, John]

On Tuesday, June 25, 2024 12:42 PM, meator <meator.dev at gmail.com>

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

I think where you say "less reliable", it would be more apt to say "unacceptable
to the overall community".  And even if it were not the original intent that
both approaches should be acceptable, if that is the de facto interpretation
then that's the position from which any changes or interpretations must be
made.  Though in truth, I have trouble reading the spec as intending otherwise.

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

The way I see it, no, I don't.  On one hand, none of the specifics laid out in
that draft wording are rules in their own right.  They are all _consequences_
of the general rule that an implementation should have its choice of
running the command via a shell or parsing the command line and
exec()ing the result directly.  On the other hand, that general rule seems
to convey the prevailing interpretation of the spec, so even though some
of those specifics are not spelled out in the current spec, they are
nevertheless implied by it anyway.

> This would remove
behavior discrepancies between the shell approach and the manual approach.

Yes, to the extent that there are any desktop files that actually trigger such
differences now.  But I'm inclined to think that those tend to get ironed out
when a project gets bug reports about its desktop files not working with
one desktop environment or another.  Which is another reason to take what
I describe as a more explicit expression of the de facto requirements of the
current spec, rather than as conveying any new or fundamentally different
requirements.

> One disadvantage I see is that the entire shell quoting mechanism has to
> be specified here.

No, it doesn't.  In fact, it _isn't_ (believe it or not) in the draft wording I
presented (see also below).

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

Shell _is_ directly related to desktop files if it is a rule, whether explicit
or not, that the value of the Exec key needs to be interpretable in a
certain way by the shell.  And although the spec doesn't say so
explicitly, I do, again, think that that is a de facto rule.  Specifically,
as I expressed it in the draft text: "commands must be quoted and
escaped such that their interpretation according to the shell's rules
does not differ from their interpretation according to the more
limited delimiting, quoting, and escaping rules presented in this
specification."

However, having expressed that rule in the spec, it would be possible to
provide less precise guidance on how to satisfy that, closer in style to
the current quoting rules.  One needs to understand, however, that
the current rules are inadequate for their apparent intended purpose.
If we are interpreting that purpose correctly then that is a deeper flaw
in the spec than just not covering square brackets, yet one that I don't
think would be a major issue to fix, even if the change could be
interpreted as backwards incompatible.

> the main issue I've outlined in the
> originating e-mail of this thread is globbing.

Yes, I know and understand.

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

Yes.

> Implementations doing word splitting and unquoting manually will see
> /usr/bin/xte[r]m,

Yes.

> which is arguably the correct behavior.

Maybe.  Inasmuch as I perceive a de facto rule that Exec values must be
quoted appropriately to ensure that there is no such difference in
interpretation, I would argue that that Exec value is non-conforming.
If it appeared in a real desktop file, I would find it eminently reasonable
to file a bug report about that with the project providing that file.

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

Agreed.  And the general rule I keep coming back to is consistent with
that.

> I would also like to point out that "real" desktop files used in
> production will never contain these special edge-cases were discussing.

Provisionally agreed.  Certainly I don't expect ever to see anything
analogous to Exec=/usr/bin/xte[r]m.  But I'm not so quick to accept
that I shouldn't expect ever to see *any* real-world example that satisfies
the explicit quoting rules in the current version of the spec, but
nevertheless is handled differently by different desktop environments.
Such an example probably wouldn't involve square brackets, but I
am in no way so sure about shell reserved words, for example.

> But still, the specification should be clear.

Yes.  I may just submit a PR with some variation of my draft revision,
and see what happens.

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

Although that puts more work on the desktop file launcher, I do think
it's the preferable approach.  I never like to get a shell involved unless it's
really needed.


Best,

John


________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240625/a68e1730/attachment-0001.htm>