"DBus Embedded" - a clean break

Rémi Denis-Courmont remi at remlab.net
Thu Jan 20 11:21:50 PST 2011

Le jeudi 20 janvier 2011 21:01:51 Havoc Pennington, vous avez écrit :
> Hi,
> 2011/1/20 Rémi Denis-Courmont <remi at remlab.net>:
> >> Do not do any verification is clearly faster, but is already possible
> >> with a 1-line change to the current code (grep for
> > 
> > Hmm... AFAIU, that would imply a change to the protocol and
> > specification. The final destination namely needs to discard invalid
> > messages instead of closing the entire connection.
> The spec is more "should" than "must" on this point I think, it
> doesn't affect interoperability, just whether your implementation is
> secure against untrusted peers.
> There's also two kinds of validity checked. One is well-formedness,
> violations there are assumed malicious (or at least wildly
> incompetent) so the connection drops. The other is higher-level
> semantic problems, which result in an error reply.

Bah, nobody is ever going to agree on the boundary between broken and evil.

Better just drop all messages that are broken to the point that you cannot 
parse them, a.k.a. the (receiving half of the) Jon Postel principle.

> it's the difference between bad xml like:
>   <<p><script> a href=broken"
> and bad html like:
>  <imadeupthistag>foo</imadeupthistag>
> > In real life, you will never get even close to the complete N! graph.
> It does get big though, and has in empirical practice. Apps that
> provide a service end up having connections to lots of other
> processes.
> Anyhow this could be easily quantified precisely with actual data on a
> running gnome desktop.
> > and if arrays had an item count in addition to a total bytes
> > length.
> Can't you just do bytelen/sizeof(element) ?

That only works for fixed size elements, i.e. scalar types and composite types 
made only of scalars. If you need to know the size of an array, you end up 
iterating it twice...

Rémi Denis-Courmont

More information about the dbus mailing list