For Bug #37890, we prevented accidental eavesdropping and made it opt-in. We should document that (which implies defining eavesdropping in the spec).
Created attachment 49391 [details] [review] [PATCH 1/5] spec: make the Match Rules section true again The spec previously claimed that only messages matching the client's match rules would be received. This is not actually true: messages listing a client as their DESTINATION are always delivered (security policy permitting).
Created attachment 49392 [details] [review] [PATCH 2/5] spec: define unicast messages and broadcast signals, and explicitly allow unicast signals I believe that the wording of the spec has always allowed unicast signals, but most bindings assume that signals are broadcasts, so it seems worth saying specifically that this feature exists and can be useful. --- Thiago will hopefully appreciate this patch, since the existence of unicast signals came as a surprise to him :-)
Created attachment 49393 [details] [review] [PATCH 3/5] Define eavesdropping, and document the eavesdrop match
Created attachment 49394 [details] [review] [PATCH 4/5] Move the explanation of message routing to the Message Routing section, leaving behind a summary
Created attachment 49395 [details] [review] [PATCH 5/5] spec: mention that buses may have a security policy, but leave it implementation-specific
Review of attachment 49391 [details] [review]: r+ from me
Review of attachment 49392 [details] [review]: r+ from me
Review of attachment 49393 [details] [review]: r=me too, with a small question. ::: doc/dbus-specification.xml @@ +3917,3 @@ + if the security policy of the message bus allows it. + </para> + <para> Is this empty paragraph intentional?
Review of attachment 49394 [details] [review]: r=me
Review of attachment 49395 [details] [review]: r=me. Ship it!
Was fixed in 1.5.6
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.