[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: Escaping for paths
From: Kimmo =?ISO-8859-1?Q?H=E4m=E4l=E4inen?= <kimmo.hamalainen () nokia ! com>
Date: 2006-06-22 8:35:40
Message-ID: 1150965340.14110.40.camel () localhost ! localdomain
[Download RAW message or body]
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
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic