[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released

[Havoc Pennington]

Kimmo Hämäläinen wrote:
> I'm not asking this. I think it's enough that we have some static,
> boolean variable OOM_happened in the library and that could be queried
> with a function. (The variable could be reset by the user, so that we
> don't need to add reseting it to each public function.) This way we
> would not need more DBusErrors or breaking the API.
> 
> If we have this and the validation functions (I could provide them,
> directly or indirectly), then I think one has the chance to build robust
> software on top of the library.

I don't understand - if you're going to call the validation functions 
then you won't pass invalid args in, so a return value of FALSE _means_ 
out of memory - what is the OOM_happened for?

OOM_happened is not threadsafe among other issues...

> Yes, I understand that everything can be done in bindings and client
> programs. However, as it requires more code, the developer is usually
> too lazy to do it, unless it's really easy.

I consider it a given that if you receive untrusted data from file or 
network, you are going to validate it. That's simply how writing 
software works. Having every function validate everything is both 
incredibly high-maintenance and cpu-intensive.

Look at a simple gtk API like gtk_label_set_text(). This is going to 
call pango_layout_set_text which will call various additional pango 
functions that all take the string. If all of these validate the UTF-8, 
you have validated the same string about 50 times.

On top of that, most commonly the string is a literal from the app, so 
can't possibly be invalid.

The alternative (which gtk uses) is that if you read in a file, you 
validate the file. Then, you can pass it to the library functions.

There's a g_return_if_fail(g_utf8_validate()) somewhere (I think in 
pango_layout_set_text()) just to make it easy to debug if you mess this 
up, but there's no API commitment - you need to validate yourself. It's 
not like "text doesn't appear" is reasonable behavior for users to see 
anyway. The right user behavior is an error dialog "this file is 
invalid", which is another reason the validating code should be when the 
file is loaded.

> What about the case of a D-Bus library wrapper.

You're right, if you want a library wrapper that allows programmers to 
pass in arbitrary junk, then you have to treat your function arguments 
just like a file or network stream and validate them all.

It's 100% possible to implement this on top of libdbus, however libdbus 
does not do it for you because for most apps it makes no sense to add 
that kind of overhead.

> I know already that Glib is broken (at least in OOM-sense in embedded
> environment), but I would not make the same mistake in D-Bus, since it
> must be usable also in the lowest levels (e.g. daemons that cannot be
> restarted if they crash).

I don't think there's an issue here of being able to detect OOM with 
libdbus. The libdbus API contract clearly allows reliably detecting OOM. 
It's simply a matter of how convenient it is in an application that 
wants to be able to pass junk to any function and not crash. I think 
allowing junk arguments is both a significant additional maintenance 
burden on libdbus and a significant performance overhead for most apps, 
with little benefit in the two primary defined libdbus use cases 
(desktop session bus, linux system bus).

Havoc