Bug 39450 - document eavesdrop='true' in the spec, and what eavesdropping is
document eavesdrop='true' in the spec, and what eavesdropping is
Status: RESOLVED FIXED
Product: dbus
Classification: Unclassified
Component: core
1.5
Other All
: medium normal
Assigned To: Simon McVittie
John (J5) Palmieri
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-21 09:06 UTC by Simon McVittie
Modified: 2011-08-26 07:11 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
[PATCH 1/5] spec: make the Match Rules section true again (2.25 KB, patch)
2011-07-21 09:07 UTC, Simon McVittie
Details | Splinter Review
[PATCH 2/5] spec: define unicast messages and broadcast signals, and explicitly allow unicast signals (2.67 KB, patch)
2011-07-21 09:08 UTC, Simon McVittie
Details | Splinter Review
[PATCH 3/5] Define eavesdropping, and document the eavesdrop match (4.36 KB, patch)
2011-07-21 09:08 UTC, Simon McVittie
Details | Splinter Review
[PATCH 4/5] Move the explanation of message routing to the Message Routing section, leaving behind a summary (6.70 KB, patch)
2011-07-21 09:08 UTC, Simon McVittie
Details | Splinter Review
[PATCH 5/5] spec: mention that buses may have a security policy, but leave it implementation-specific (1.09 KB, patch)
2011-07-21 09:09 UTC, Simon McVittie
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Simon McVittie 2011-07-21 09:06:00 UTC
For Bug #37890, we prevented accidental eavesdropping and made it opt-in. We should document that (which implies defining eavesdropping in the spec).
Comment 1 Simon McVittie 2011-07-21 09:07:13 UTC
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).
Comment 2 Simon McVittie 2011-07-21 09:08:21 UTC
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 :-)
Comment 3 Simon McVittie 2011-07-21 09:08:39 UTC
Created attachment 49393 [details] [review]
[PATCH 3/5] Define eavesdropping, and document the eavesdrop match
Comment 4 Simon McVittie 2011-07-21 09:08:58 UTC
Created attachment 49394 [details] [review]
[PATCH 4/5] Move the explanation of message routing to the Message  Routing section, leaving behind a summary
Comment 5 Simon McVittie 2011-07-21 09:09:44 UTC
Created attachment 49395 [details] [review]
[PATCH 5/5] spec: mention that buses may have a security policy, but  leave it implementation-specific
Comment 6 Thiago Macieira 2011-07-29 08:13:23 UTC
Review of attachment 49391 [details] [review]:

r+ from me
Comment 7 Thiago Macieira 2011-07-29 08:15:02 UTC
Review of attachment 49392 [details] [review]:

r+ from me
Comment 8 Thiago Macieira 2011-07-29 08:19:17 UTC
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?
Comment 9 Thiago Macieira 2011-07-29 08:21:57 UTC
Review of attachment 49394 [details] [review]:

r=me
Comment 10 Thiago Macieira 2011-07-29 08:22:55 UTC
Review of attachment 49395 [details] [review]:

r=me.

Ship it!
Comment 11 Simon McVittie 2011-08-26 07:11:54 UTC
Was fixed in 1.5.6