> As I understand from DBus Spec, it should be implemented totally just like
> the org.freedesktop.DBus interface. That means:
> 
> 1. you can get its introspect data by calling
> org.freedesktop.DBus.Introspectable.Introspect
> 
> 2. the method_return message is fully filled up, with sender and destination.
> 
> 3. remove the partially implement code
> 

I think it's better to keep the partially implement code, for compatibility and peer mode.

Triaging to low/minor unless you have a concrete reason why the dbus-daemon needs to implement Peer. In fact, I'd be tempted to say "the dbus-daemon is special and different, this is just one of the many ways" and close this WONTFIX.

(A much more prominent example of how the dbus-daemon is special is that org.freedesktop.DBus is syntactically a well-known name, but behaves much more like a unique name.)

(In reply to comment #0)
> As I see, the org.freedesktop.DBus.Peer interface hasn't been implemented
> (or partially) by message bus so far.

o.fd.DBus.Peer is somewhat special: at least as implemented in libdbus, it's implemented directly by the library itself, not by higher layers. For instance, it means you can reliably "ping" an application, and means every application has a trivial no-op method that can be used to activate it. I believe reimplementations like GDBus, libsystemd-bus and dbus-java (should) do the same.

> 1. The org.freedesktop.DBus.Peer introspect data doesn't showed up by
> org.freedesktop.Introspectable.Introspect

I consider this to be valid (but including it in the response would be equally valid). It won't usually show up in applications' introspection data either, because it's implemented by libdbus (or GDBus, libsystemd-bus, dbus-java, etc., as appropriate), not by the application. If we added a third method to Peer, the application wouldn't know that it should add that to the introspection data.

> $ dbus-send --print-reply / org.freedesktop.DBus.Peer.GetMachineId
> method return sender=(null sender) -> dest=(null destination) reply_serial=2
>    string "d07462fd4a0103da2a889de200000005"

You sent a message "to no destination". I think it's valid that the reply "had no sender" (the reply's destination should be the unique name of the call's sender, not null, but I don't know whether that's really worth fixing - I suspect it'll be harder than you think).

If you send it to the pseudo-bus-name org.freedesktop.DBus, you get an error back:

dbus-send --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.Peer.GetMachineId
Error org.freedesktop.DBus.Error.UnknownInterface: org.freedesktop.DBus does not understand message GetMachineId

which is arguably also a bug: it should reply normally.

Implementation detail: the reason that the sender is "wrong" is that when operating via a dbus-daemon, the implementation of Peer (or in fact any method reply) doesn't normally need to set a sender, because the dbus-daemon will edit the message as it goes past, to set a correct, unspoofable sender; and when operating in peer-to-peer mode, senders and destinations typically aren't used at all.

(In reply to comment #1)
> I think it's better to keep the partially implement code, for compatibility
> and peer mode.

The dbus-daemon *is* a peer of the client, if you look at it from the right angle; it's just a user of libdbus like any other, and doesn't do anything that another libdbus user couldn't do (admittedly, it uses some internal APIs that aren't available to random applications, but that doesn't affect what happens "on the wire").

(In reply to comment #2)
> Triaging to low/minor unless you have a concrete reason why the dbus-daemon
> needs to implement Peer. In fact, I'd be tempted to say "the dbus-daemon is
> special and different, this is just one of the many ways" and close this
> WONTFIX.

Hmm, when i was reading the below line in DBus Spec

" The reference implementation handles this method automatically."

I thought "the reference implementation" is the message bus, however, I was wrong given that it should means the both (reference libdbus and dbus-daemon?)

So from libdbus side, yes, it handles o.f.DBus.Peer interface automatically while the dbus-daemon doesn't implement o.f.DBus.Peer interface.

> 
> (A much more prominent example of how the dbus-daemon is special is that
> org.freedesktop.DBus is syntactically a well-known name, but behaves much
> more like a unique name.)
> 
> (In reply to comment #0)
> > As I see, the org.freedesktop.DBus.Peer interface hasn't been implemented
> > (or partially) by message bus so far.
> 
> o.fd.DBus.Peer is somewhat special: at least as implemented in libdbus, it's
> implemented directly by the library itself, not by higher layers. For
> instance, it means you can reliably "ping" an application, and means every
> application has a trivial no-op method that can be used to activate it. I

Yes, this is just like there is a default o.f.DBus.Introspectable handler in libdbus.

> believe reimplementations like GDBus, libsystemd-bus and dbus-java (should)
> do the same.
> 
> > 1. The org.freedesktop.DBus.Peer introspect data doesn't showed up by
> > org.freedesktop.Introspectable.Introspect
> 
> I consider this to be valid (but including it in the response would be
> equally valid). It won't usually show up in applications' introspection data
> either, because it's implemented by libdbus (or GDBus, libsystemd-bus,
> dbus-java, etc., as appropriate), not by the application. If we added a
> third method to Peer, the application wouldn't know that it should add that
> to the introspection data.
> 
> > $ dbus-send --print-reply / org.freedesktop.DBus.Peer.GetMachineId
> > method return sender=(null sender) -> dest=(null destination) reply_serial=2
> >    string "d07462fd4a0103da2a889de200000005"
> 
> You sent a message "to no destination". I think it's valid that the reply

Yes, because currently only null destination can trigger this code path.

> "had no sender" (the reply's destination should be the unique name of the
> call's sender, not null, but I don't know whether that's really worth fixing
> - I suspect it'll be harder than you think).

I didn't investigate how peer mode looks like, but for the widely used bus/client mode, the message sender/destination is easy to get from message. I think this is a worth fix for libdbus.

> 
> If you send it to the pseudo-bus-name org.freedesktop.DBus, you get an error
> back:

Yes, so I send to a null destination above, because the reference message bus doesn't handle o.f.DBus.Peer interface.

> 
> dbus-send --print-reply --dest=org.freedesktop.DBus /
> org.freedesktop.DBus.Peer.GetMachineId
> Error org.freedesktop.DBus.Error.UnknownInterface: org.freedesktop.DBus does
> not understand message GetMachineId
> 
> which is arguably also a bug: it should reply normally.

Because the libdbus set route peer message to true(dbus_connection_set_route_peer_messages()), so if the destination isn't null, then the message to call o.f.DBus.Peer get routed to the destination.

But at meanwhile, the message bus doesn't implement o.f.DBus.Peer, so the above error happen.

> 
> Implementation detail: the reason that the sender is "wrong" is that when
> operating via a dbus-daemon, the implementation of Peer (or in fact any
> method reply) doesn't normally need to set a sender, because the dbus-daemon
> will edit the message as it goes past, to set a correct, unspoofable sender;
> and when operating in peer-to-peer mode, senders and destinations typically
> aren't used at all.

I don't get you here, what's the "sender is "wrong""? Yes, it's the message bus which set sender of message before it route the message. So both sender and dest are meaningless in peer-to-peer mode, because there are only two ends of a transport.

> 
> (In reply to comment #1)
> > I think it's better to keep the partially implement code, for compatibility
> > and peer mode.
> 
> The dbus-daemon *is* a peer of the client, if you look at it from the right

Yes, it handles the well-known org.freedesktop.DBus interface just like other client provides other well-known service.

> angle; it's just a user of libdbus like any other, and doesn't do anything
> that another libdbus user couldn't do (admittedly, it uses some internal
> APIs that aren't available to random applications, but that doesn't affect
> what happens "on the wire").

Last, when I was opening this bug, I was thinking "The reference implementation" as the reference message bus, so I said "o.f.DBus.Peer hasn't been implemented (or partially, in fact, this is libdbus)".

So for this bug: Is it worth to implement o.f.DBus.Peer in the reference message bus now is an open.

And for the "null sender and null destination" in method reply of o.f.DBus.Peer in libdbus. As far as I can tell, the currently implementation is implemented for peer-to-peer mode where the message destination is null. In the bus/client mode, Destination is required for method_call as I known. So if this is true, the "null sender and null destination" is reasonable.

I think we need some more background story from Havoc?

> And for the "null sender and null destination" in method reply of
> o.f.DBus.Peer in libdbus. As far as I can tell, the currently implementation
> is implemented for peer-to-peer mode where the message destination is null.
> In the bus/client mode, Destination is required for method_call as I known.

Oops, not required, this is how I triggered that part of code in #comment1

> So if this is true, the "null sender and null destination" is reasonable.
> 
> I think we need some more background story from Havoc?

I implemented this on Bug #101257.

*** This bug has been marked as a duplicate of bug 101257 ***