<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">I also fail to see how having a token is any better than declaring relative<br></span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">paths to be searched from $PWD. Can you shed more light on this suggestion?</span></blockquote><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">$PWD is something that a user or administrator may change for many different reasons, not to mention it's different per-user. Relying on this for dbus invocation may lead to all kinds of hard-to-debug surprises and perhaps open up attack vectors.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">Tying yet-another-thing into that same environment value means that you tie more opportunities for failure into a thing users typically fiddle with.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">If the goal is to support alternative or non-standard or isolated installs of dbus, then having one place that defines what "search start" means FOR THAT INSTALL would be the most robust and secure solution,.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">On Windows, that might be a registry value that is specific to dbus.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">On Linux, that could be a symlink in /etc/alternatives, for example. (This is an illustrative example, not a soup-to-nuts considered proposal)</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">However, I think the system would be simpler and more secure if relative search just didn't exist. If the only actual, needed-right-now, reason to introduce relative search is for Windows support, then I don't think that use case is important enough to relax the potential security and complexify the implementation and administration.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">Sincerely,</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">jw</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="courier new, monospace"><br><br><br><font>Sincerely,</font><br><br><font>Jon Watte</font><br><br><br>--<br>"<span style="color:rgb(0,0,0)">I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson</span></font></div></div>
<br><div class="gmail_quote">On Wed, Sep 10, 2014 at 11:40 AM, Thiago Macieira <span dir="ltr"><<a href="mailto:thiago@kde.org" target="_blank">thiago@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday 09 September 2014 18:01:55 Jon Watte wrote:<br>
> > Simon's email explained the use-case: relocatable installations,<br>
> > especially on<br>
> > Windows.<br>
><br>
> I don't think that's strong enough to open up a security can of worms.<br>
> If you want relocation, use some token system (like how Scons has "#" for<br>
> "root of build")<br>
> And if the main use case is for Windows, then again I'd look carefully at<br>
> actual numbers of users/installs and ability to capture that market, and<br>
> discount the value of that support appropriately.<br>
> Maybe not everyone agrees with that sentiment, but it's a largely<br>
> observable truth :-)<br>
<br>
</span>If you feel there are security implications, please say so. If there are<br>
issues, then the desktop spec needs to address them one way or another. We<br>
could choose one of Simon's three suggestions or outright ban the practice.<br>
But all desktops need to be fixed to deal with this correctly.<br>
<br>
I also fail to see how having a token is any better than declaring relative<br>
paths to be searched from $PWD. Can you shed more light on this suggestion?<br>
<br>
In any case, D-Bus would like to follow the same specification as .desktop<br>
files, but it could diverge if necessary to meet its unique requirements.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" target="_blank">kde.org</a><br>
   Software Architect - Intel Open Source Technology Center<br>
      PGP/GPG: 0x6EF45358; fingerprint:<br>
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358<br>
<br>
</div></div></blockquote></div><br></div>