6 ms·

How else would you get DNS responses in XML over DBus? ;)

by qb45 9y ago

deno 9y ago
DBus only uses XML for its introspection interface. There’s really no reason why you couldn’t switch it to anything else like tomorrow. Specifically, DBus does not use XML for any message passing or data serialization. It uses its custom binary on-wire format. Also to consume or provide DBus services you do not need to interact with any XML whatsoever (except maybe for Polkit but that’s not DBus).
- cyphar 9y ago
  > There’s really no reason why you couldn’t switch it to anything else like tomorrow. Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate? > It uses its custom binary on-wire format. Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
  - deno 9y ago
    > Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate? You can put DBus server behind a proxy that handles that for you. The XML format is very simple and it doesn’t change. My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored. XML is only used for introspection, a debug protocol on top of DBus. > Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels. DBus is a message-passing protocol. You can write it in anything you like. You could have DBus server that talks Protocol Buffers or JSON if you like, as long as you provide gateway for legacy clients.
    - cyphar 9y ago
      > My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored. Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time). > DBus is a message-passing protocol. You can write it in anything you like. The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon. Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.
      - jononor 9y ago
        Isn't dbus-daemon and kdbus (in a couple of incarnations) different implementations?
        deleted 9y ago
        [deleted]
        cyphar 9y ago
        kdbus was a different implementation, but I was under the impression that kdbus was "only" a routing implementation (though in truth that's all that dbus-daemon is anyway). However, kdbus never landed anywhere and it has been abandoned in favour of bus1: https://www.youtube.com/watch?v=6zN0b6BfgLY https://www.youtube.com/watch?v=6zN0b6BfgLY.
      - deno 9y ago
        > But how many implementations currently exist? One. I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation. Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.
  - JdeBP 9y ago
    Ahem! The DNS protocol itself qualifies as a "custom binary on-wire format" in this regard. Be careful with this argument. (-:

How else would you get DNS responses in XML over DBus? ;)

by qb45 9y ago

How else would you get DNS responses in XML over DBus? ;)

deno 9y ago

DBus only uses XML for its introspection interface. There’s really no reason why you couldn’t switch it to anything else like tomorrow. Specifically, DBus does not use XML for any message passing or data serialization. It uses its custom binary on-wire format. Also to consume or provide DBus services you do not need to interact with any XML whatsoever (except maybe for Polkit but that’s not DBus).

cyphar 9y ago
> There’s really no reason why you couldn’t switch it to anything else like tomorrow. Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate? > It uses its custom binary on-wire format. Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
- deno 9y ago
  > Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate? You can put DBus server behind a proxy that handles that for you. The XML format is very simple and it doesn’t change. My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored. XML is only used for introspection, a debug protocol on top of DBus. > Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels. DBus is a message-passing protocol. You can write it in anything you like. You could have DBus server that talks Protocol Buffers or JSON if you like, as long as you provide gateway for legacy clients.
  - cyphar 9y ago
    > My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored. Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time). > DBus is a message-passing protocol. You can write it in anything you like. The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon. Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.
    - jononor 9y ago
      Isn't dbus-daemon and kdbus (in a couple of incarnations) different implementations?
      - deleted 9y ago
        [deleted]
      - cyphar 9y ago
        kdbus was a different implementation, but I was under the impression that kdbus was "only" a routing implementation (though in truth that's all that dbus-daemon is anyway). However, kdbus never landed anywhere and it has been abandoned in favour of bus1: https://www.youtube.com/watch?v=6zN0b6BfgLY https://www.youtube.com/watch?v=6zN0b6BfgLY.
    - deno 9y ago
      > But how many implementations currently exist? One. I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation. Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.
- JdeBP 9y ago
  Ahem! The DNS protocol itself qualifies as a "custom binary on-wire format" in this regard. Be careful with this argument. (-: