[PATCH] No longer need to escape '+' in a D-Bus address

[Havoc Pennington]

Hi,

On Fri, Aug 29, 2008 at 3:14 AM, Michael Witten <mfwitten at mit.edu> wrote:
>>>   <listen>unix:tmpdir=/var/folders/9Y/9YL5MvFhGfySA5DvYnUpJE+++TI/-
>>> Tmp-/</listen>
>>>
>>
>> When you say "was produced," how was it produced, and why isn't it
>> escaped properly?
>
> In any case, the configuration of the dbus source is affected by these
> definitions of
> $TMPDIR.

So, when dbus is configured, this thing just needs to be escaped. I
don't think changing the set of allowed chars is the right solution
(in general) whenever someone is failing to escape a string. 'sed'
should be perfectly capable of escaping this in 1 line of shell.

It's possible we should change the set of allowed chars for some other
reason, but this OS X porting bug seems like just a plain old bug, "on
OS X the tmpdir path is not escaped in configure" - I don't think it's
really related to a discussion of which chars should require escaping.

> Do you want me to patch these things?

Only if we decide we want to add "+" - I don't really see the case for
doing so, though, in light of the headaches of making a change here.

> Because the OS assigns a temporary directory to each user, the
> configuration
> script(s) would have to take special pains to check for this (and any
> other
> offensive) character and then automatically escape it.

And that is true even if we add "+" to the list that doesn't require
escaping, someone at least has to think about this.

> The alternative is to loosen the specification (for at least file
> hierarchy
> "addresses"), which seems acceptable to me.

If you loosened it to never require escaping, or proved that "+" was
the only possible escape-requiring char in this context, then it would
be slightly easier to fix this OS X bug. But every time someone has a
filename with a char that requires escaping, loosening the list of
escape chars is not going to be the fix every time.

It doesn't follow then, from my perspective, that whenever someone has
an escape-requiring char we stop requiring its escaping. Changing the
escaped-char list needs a little more justification.

>
> It's really just a matter of deciding who has to do the grunt work---

The grunt work in this case, assuming "+" is the only escape-requiring
char, is to add 1 line "sed -e" that replaces "+" with "%2B", so I
vote for the OS X port maintainer.

>        Frankly, enforcing (arbitrarily) strict input is never a good idea,
>        and I suggest making dbus more forgiving on a wide range of characters
>        (for instance, all printable characters).

Then people would have to do grunt work in quite a few cases to
*escape* rather than unescape dbus addresses, to prevent them from
causing a problem in shell command lines.

The point of requiring escaping is to allow dbus addresses to be used
without shell-escaping them in contexts such as setting
DBUS_SESSION_BUS_ADDRESS on the command line.

"+" is actually fine from this point of view, but still I think we
should have a pretty good reason to modify a supposedly-1.0 spec. As
long as any escaping is required, we haven't really removed any burden
from most contexts in which addresses are created. Poking around the
edges seems like all churn no gain.

The point of not requiring *all* chars to be escaped is that it makes
the address mostly human-readable and much shorter.

Havoc