Escaping for paths

Kimmo Hämäläinen kimmo.hamalainen at
Thu Jun 22 01:35:40 PDT 2006

On Thu, 2006-06-22 at 01:50, ext Havoc Pennington wrote:
> Kimmo Hämäläinen wrote:
> >
> > Yes, I guess so, but Havoc said that sending invalid messages is an
> > application bug, so that validation in DBus library could go away when
> > application has the means to validate the messages. Also, it could
> > reduce the amount of needed function calls, when the message has many
> > arguments. Not to mention that it would allow more flexible architecture
> > in the application, since the caller does not need to no anything about
> > the message.
> > 
> The main problem with validating inside dbus_message_append_args() or 
> whatever is that it would add the need for a DBusError return.
> I don't think this makes sense, because we're talking about a very 
> uncommon case:
>   -> untrusted data used for an object path (already uncommon)
>     -> wanting to _fail_ (validate) rather than _escape_ in this case
>        (more uncommon still)
> Essentially this only happens when a program takes a dbus object path on 
> the command line, or something like that.
> Other cases would be something like the "/addressbook/<URI>" example and 
> then you want escaping, not validation.
> So, why add the annoying DBusError return for this odd case.

I was talking about a new function that would allow validating a whole
DBusMessage. (My comment was a response to Ross' e-mail about new
validation functions.) Breaking the old API is not a good idea.

BR, Kimmo

> Havoc

More information about the dbus mailing list