[ANNOUNCE] D-Bus Broker Project

Tom Gundersen teg at jklm.no
Sat Sep 9 12:06:40 UTC 2017

On Sat, Sep 9, 2017 at 3:12 AM, Thiago Macieira <thiago at kde.org> wrote:
> On Thursday, 7 September 2017 13:26:01 -03 David Herrmann wrote:
>> Those messages have never been
>> considered solicited. Hence, there has always been the issue of
>> malicious peers triggering those messages without dispatching them.
>> In my opinion, those APIs should take object-paths as input, to
>> describe the new subscriber. So image you want to subscribe to
>> device-events, you would call:
>>     SubscribeDevice(o device, o subscriber, ...)
>> The subscriber object-path would then be used in the *directed*
>> signals, to allow the caller to install matches on them before
>> actually subscribing. This has many more benefits, btw. For instance,
>> you can cancel your subscription before the subscribe call returns
>> (because you already know the object-path of the subscription).
> This has the drawback that the client needs to guess an object path on the
> service that is unique and not in use by some other client. That means the
> call may fail because of a collision. The client now needs to have code to
> handle this and re-issue the call with a new path.

This could easily be solved by the server enforcing a scheme on the
object names the client can chose from. One possibility would be:

<common prefix enforced by server>/<client's unique name>/<suffix
chosen by client>



More information about the dbus mailing list