This is an old revision of the document!

Failure of D-Bus

With hyperbolaBSD, d-bus and related linux specific frameworks will eventually be deprecated, according to our Roadmap With release of version 0.4, the end of support for D-Bus was marked among other inovations.


D-Bus is over-engineered and orphaned, ussually on critical systems which prioritize privacy, security and freedom like hyperbola, it becomes unecessary and avoidable. In fact, pure C API is quite laborious and its use, requires writing large amounts of boilerplate code, to the point where its own API documentation states: “If you use this low-level API directly, you're signing up for some pain.” Therefore the adopting of this kinds of frameworks is hard to respect modular and lightweight premisses and by consequence our Social Contract. While atack surface is massively and exponentional increased.

What are the issues?

There are many nasty, absurd open bugs and also known vunerabilities, as well as conceptual problems in d-bus codebase. The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation.

Privacy problems

Not to speak that D-Bus leaks machine-id across applications and userland which causes concerns on what regards to privacy, fingerprinting, and user control.


In packages where D-Bus is required, explore ubus, gio and kio as possible replacements, dbus-broker isn't a solution because it requires bus-1 (D-Bus inside kernel) and libsystemd.

Ubus is the planned D-Bus replacement for those packages where D-Bus is required, however its development was focused to be used in OpenWrt for embedded machines and contains a different syntax.

more research is needed to see if its possible the adoption in a more complex environment.