How not to use dbus (in cars or anywhere else)

[Thiago Macieira]

On Tuesday 25 August 2015 19:52:06 Simon McVittie wrote:
> On 25/08/15 18:56, Thiago Macieira wrote:
> > Are you sure the order of events are right? Wasn't the nonce-tcp created
> > first?
>     2003-03-04  Havoc Pennington  <hp at pobox.com>
>        * dbus/dbus-auth.c: replace DBUS_STUPID_TEST_MECH auth
>         with DBUS_COOKIE_SHA1, implement DBUS_COOKIE_SHA1
> 
> compared with
> 
> Author: Frank Osterfeld <frank at kdab.net>
> Date:   2009-10-21 19:52:49 +0300
> 
>     The current state of the nonce-tcp implementation
> 
> during a batch of merging changes from dbus4win. I don't *think*
> dbus4win existed yet in 2003, but I could be wrong.

True. Out of curiosity, Frank, do you remember what the reason was for using 
nonce-tcp instead of the cookie method? "We didn't know it existed" is a valid 
answer :-)

I can only speculate that the nonce-tcp method was also going to get used in 
other non-D-Bus contexts where Unix sockets were being used.

> > Anyway, we've been saying over and over again that D-Bus over the network
> > is a bad idea. We don't support it and we don't plan on supporting it.
> 
> Right. So perhaps instead of not supporting it (as in "if it breaks you
> get to keep both pieces"), 1.11 should not support it (as in ENOTSUP),
> at least for some of the more egregious bits?

I think we should do it.

> > If you want D-Bus over a network, maybe you should consider looking at
> > AllJoyn. They've implemented authentication underneath a distributed
> > D-Bus.
> 
> An interesting project. I'm a little disappointed that none of its
> developers seem to have mentioned it on this list.

Yeah, same here. I only found out about it because $WORK required me to 
compare it to the competing IoT solution we're developing.

I was wondering if we should renumber the ALLOW_INTERACTIVE_AUTHORIZATION flag 
to their unused bit (0x10, I think).

In any case, a simple look at the end-to-end encryption mechanism they are 
using encrypts only the D-Bus message body, not the header, so the method 
name, object path, interface name, error name, and signature are all sent 
unencrypted. That's leaky, so I'd expect a message payload change soon that 
won't keep backwards compatibility.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358