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

[Dalleau, Frederic]

Tanu,

On Wed, May 9, 2012 at 1:16 PM, Tanu Kaskinen <tanu.kaskinen at digia.com> wrote:
> 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.

I'd say that as a maintainer, you have chosen to link a library after a careful
selection process. You have the same responsibility when choosing a library
that for code you have personally written.

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

Understood, but I think the title of this discussion is confusing ;)

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

The error handling don't have to be necessarily complex (goto fail?).
And the use of an assertion creates the perception that PulseAudio has
crashed, whereas in this case (if it ever happened) the bug would not be
in pulse.

Let's put the question another way : What is the benefit at not being paranoid?

Frédéric