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

[Kimmo Hämäläinen]

On Mon, 2006-09-18 at 23:18, ext Havoc Pennington wrote:
> 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?

You can never be entirely sure that the arguments are valid, because you
don't necessarily have the same information as the library has. In some
cases it could even happen that the arguments become invalid after you
have validated them but before you had the chance to call the function.

> OOM_happened is not threadsafe among other issues...

That's solvable. (E.g. by saying in docs that it's not thread-safe.)

> > 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.

I'm not proposing more validation to be done by the library.

> 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.

Again: I'm not proposing more validation.

> > 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).

It's an issue to detect OOM, as I have said above. I think D-Bus API
should allow unconditional detection of OOM, as any sensible API does.

BR; Kimmo

> 
> Havoc
>