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
