[pulseaudio-discuss] Is it OK for PulseAudio to crash when BlueZ is buggy?

[Tanu Kaskinen]

On Wed, 2012-05-09 at 11:02 +0200, Frédéric Dalleau wrote:
> Hi Tanu,
> 
> In general, your mail sounds ok but the last sentence sounds strange :
> 
> On 05/09/2012 09:19 AM, Tanu Kaskinen wrote:
> > I think it should be
> > OK to assume that D-Bus services are working as documented, and when
> > there are problems with that, fix the bug where it is.
> 
> It is proper coding practice to check everything that is coming from 
> outside your process from environment variable and files, to user input 
> and in this case dbus api. This is the only way to have a deterministic 
> behavior. Sooner or later, you will have to deal with a deprecated dbus-api.

What makes the process boundary magic? Why do we trust libraries more
than out-of-process system services? I think tampering with either is
about as hard or easy, so I don't see any real security difference. With
untrusted input the rationale for validating everything is clear, but I
think D-Bus system services are trustworthy.

> Sooner or later, you will have to deal with a deprecated dbus-api.

I like this argument more. So with D-Bus services I can't trust that the
API stays stable. What was promised in the documentation when I wrote
the code may not hold when running the code against a newer or older
service version.

With libraries there are established conventions for ensuring that
programs aren't linked against incompatible library versions. This
*shouldn't* be any different with D-Bus services, but maybe it is? I
haven't noticed any version information in the BlueZ APIs, so maybe
there aren't any safeguards against running PulseAudio against a subtly
incompatible BlueZ version?

I'll say it again to be clear: I have so far tried to carefully validate
all input from D-Bus services, so there's no fear that I would have
littered the code with unsafe assumptions. I'm raising this topic up,
because I'd like to change that, if there are no good reasons for
continuing to be paranoid.

What triggered this was a question about what to do if BlueZ claims that
there are two devices with the same address (that should never happen).
I'd like to store the devices in a hashmap with the address as the key,
so there are complications if there are multiple devices with the same
address. Those complications can be avoided, if I do just:

pa_assert_se(pa_hashmap_put(bluetooth_core->devices_by_address, device->address) >= 0);

Why should I implement any more complex error handling?

-- 
Tanu