[systemd-devel] [PATCH 0/4] [RFC v1] gdbus: Preliminary kdbus-support patches

[Simon McVittie]

On 21/11/13 11:33, Karol Lewandowski wrote:
> [ Cced systemd-devel@ and dev at tizen mailing lists in case someone
>   there would be interested too. ]

The maintainers of the D-Bus specification and reference implementation
can be contacted via dbus at lists.freedesktop.org and the freedesktop.org
Bugzilla.

If it is your intention to redefine what "D-Bus" effectively means,
please discuss it with the relevant community, and be prepared to
justify design decisions (or change them, if it turns out something has
been overlooked).

Sorry, I don't have time to find and review the various kdbus
branches/projects right now, but perhaps another dbus committer (Colin?
Thiago? Lennart?) does.

>    Currently we use modified[3] dbus-daemon to for that
>    purpose.

If you've forked dbus-daemon, definitely please discuss it with the
people who understand that codebase.

My most important question whenever I look at D-Bus is: does this change
break existing applications? Without having reviewed anything in detail,
the major areas in kdbus that I'm concerned could break existing
software are:

* retaining message-order guarantees, or at least, explicitly
  documenting which ones have been relaxed and their impact on
  applications (in dbus-1 there is one canonical order of messages,
  and all processes see them in that order)

* having the subtler points of bus name ownership remain compatible
  (the ability to queue for name ownership, etc.)

* access control: it's fine if you want kdbus to have a less insane
  security policy language than dbus-1; but if an existing libdbus,
  QtDBus, GDBus etc. application was relying on the system dbus-daemon's
  deny-by-default policy, and a library upgrade makes it connect to
  kdbus instead of /run/dbus/system_bus_socket, then it isn't
  acceptable for that application to be instantly security-buggy

* edge cases involving large/many messages and who can DoS who, e.g.
  see https://bugs.freedesktop.org/show_bug.cgi?id=33606
  (I'm sure you've done better overall than dbus-1, but the question
  is whether anything became worse as a result)

* portability: it's fine that kdbus is Linux-specific, but everything
  that currently works on non-Linux (libdbus, GDBus etc.) should
  continue to work at least as well as it does now

Regards,
    S