Could this bus offer a dbus-compatibility 'firewall/translator' d-bus socket per each app (provided they use the d-bus environment variables correctly)? That might speed adoption if it is able to be a drop-in default, instead of needing to run 2 busses.
>I've decided to take matters into my own hands. I am writing a new bus.
Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.
You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
My knowledge is outdated, as I last seriously looked at it about nine years ago, but I doubt Binder is even better than dbus; it was not good. I'm quite surprised with people suggesting it. There was that recent kernel Binder bug even with the rust implementation. It was rewritten in rust because it has had a never-ending string of serious security bugs. On top of that, it had very poor throughput. I'm guessing this improved with the rust implementation.
It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.
I wonder if the design of D-Bus has anything to do with a principle I notice a lot, where the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness. For example, I wonder how many repos on github have legitimately created a 100% better framework than React, but the author simply can't get the word out for whatever reason, so the project remains accidentally anonymous. Maybe D-Bus has something similar?
iirc it was developed as freedesktop project in order to create standard desktop bus to be used by everybody, as back in a day kde had it's own bus and gnome had another one.
Part of what's going on is that all of this stuff is developed by volunteers. If only one person, or three people or whatever, are actually willing to give up hundreds of thousands of hours of their own time to work on something, then those people get to make the decisions about what gets done. There's very little supervision from any kind of "upper management" to catch bad decisions.
On top of that, there's adverse selection here. Who gives up thousands of hours to work on some obscure corner of the Linux desktop? People with quite unusual thought processes.
Can't you guys stop reinventing the wheel every other day? I hate D-Bus like everyone else, even though at least it did bring project Utopia and all such crap. But even if I think it sucks I stay with it for the simple reason that the more alternatives you create the more you annoy other users WAY MORE than any benefit you bring them. D-Bus has been used everywhere from LG TVs to automotives, so at least it f*cking works.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Perhaps the SecretManager deserves some extra attention, but I concur. We worked long enough on this, please dont split whats left of the linux desktop...
> Can't you guys stop reinventing the wheel every other day?
No, Linux desktop is just an opportunity for a bunch of special snowflakes to enact their "vision", force their niche requirements on other 99.999% of users or create fiefdoms, where they can feel good and safe.
Putting aside the post and whether it's correct or not.
Reinvent what wheel exactly?
D-Bus can't read your mind (yet) and as such it can't generate an API for you, you still need to design a protocol, it's just that it's on top of D-Bus with certain quirks and restrictions.
Doing the same over UDS in 2025 isn't any more work and doesn't have any negative impact on end users. There's nothing unique about D-Bus from a usability standpoint that can't be done with a service listening over UDS.
This is equivalent to saying that you're reinventing the wheel by not using HTTP as a transport.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Maybe you should look at Varlink. The systemd backed D-Bus alternative. It uses JSON.
Regarding secrets management:
My password manager's protocol is handled using exec and command line arguments. Arbitrary applications can ask for passwords, but they won't get them. They won't read them from disk.
The design of the gnome keyring isn't great, but I actually don't think the protocol matters much in this case.
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
That's not a surprise. The author of systemd, for instance, is working for Microsoft. Suddenly all those changes to the Linux ecosystem make a lot of sense. It became a corporate commodity, from A to Z. And when that is your objective, it kind of makes sense to have a unified system, even if it is crap.
> Ever seen kwallet or gnome-keyring? Yeah, these things. These are supposed to be "secret storage" for things like signing keys, passwords, etc. They can be protected by a password, which means they are secure... right? [...] any app on the bus can read all secrets in the store if the store is unlocked.
Well, TIL. Looks like the default GUI for that is `seahorse`, so let's see what I've got on a relatively fresh installation... Looks like mostly Chromium stuff where there's a key that unlocks something more application-specific (e.g. for Discord) and an access token for my JetBrains account.
So no plaintext passwords per se, but now I wonder what a malicious app might uncover if it pursued the local Chromium stuff.
A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Marsh did with ruff and uv.
He didn't barge in guns blazing proclaiming "pip is a disgrace" and "it's a fuckin joke". He wrote a tool that was much better and encourage others to try it. Within a year or so, it snowballed into an unstoppable change.
This project currently has a bunch of C++ files, no docs, no tests, no roadmap on how it might replace d-bus, nothing. And as another commenter pointed out, starting a new system service in 2025, yelling about security, and doing this in an unsafe language doesn't inspire confidence.
Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with talking like this, but if you seriosly want to bring a wide community on board (without which the entire thing is a non-starter), look to Charlie instead.
Oh, and also, if you think D-Bus is bad, consider yourself lucky you didn't need to use the thing it replaced - CORBA.
Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
Raises the obvious question of why not using the wayland protocol (on another socket, not on the compositor socket). It has mature implementations in many languages, an IDL with compilers, and every GUI application is already going to link to libwayland anyway.
The problem with dbus is also that all these nice browser extensions that integrate websites with gnome/kde talk over dbus. These dbus APIs had several DOS vulnerabilities, some of which could be triggered by visiting any website. It is unacceptable that my desktop environment crashes just because something floods the dbus API, even moreso if it can be triggered by visiting a website.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
> any app on the bus can read all secrets in the store if the store is unlocked
Holy shit. I knew conceptually that this was the case but never really took the time to consider the implications.
Pretty much whenever you unlock your keyring all your secrets are accessible by any software that can connect to the bus... How is this acceptable? Are we just supposed to run everything as Flatpak?
Funnily enough, my work macOS keychain maimed itself in such a way that I need to recreate it every time I install an OS update. Every time I recreate it, the OS spends a few minutes in a state where every application that needs access to the secrets store requests access through the keychain's password. Incredibly secure!
Turns out, that's every application, every few minutes, many of them multiple times. Applications like having access to things like refresh tokens so they can download your email, or discover passwords for offering autofill for a website.
I'd welcome many improvements to the Linux status quo, but applications not needing to ask before accessing the bus is the only reason it's usable in the first place.
It's acceptable because flatpak dbus and all its ilk are too opaque for the average "experienced" user to fully grok. The problems are there, but the situation is so convoluted that it's hard to build a mental model unless you truly understand the overall system architecture
D-Bus is over 20 years old so a reboot is in order. All this guy's gripes are not legitimate, but many are. However, upgrading desktop infrastructure is just as much about influence (clout) and "social" excellence as it is about technical exellence. A new ipc mechanism that is not backed by the major players has no chance.
This will no doubt be used by many people who use Hyprland and I really don't think Vaxry cares about anything else. He's a college kid from Poland who now is getting enough donations he probably will never have to work for someone else if he doesn't want to, and can just continue developing his own ecosystem.
> This means that when "/usr/bin/firefox" sets a "passwords:superwebsite.com = animebooba", an app called "~/Downloads/totally_legit.sh" can not see ...
It will be interesting to see how it treats symlinks in this case. Or specifically, will this idea break completely for nixos or not.
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
I do not like D-Bus either, and I do not like JSON either. Some of the problems are the ones mentioned there, and it has many other problems as well (one of these is that its use of Unicode can cause problems, but there is a lot more problems than just that). I do not agree with the solutions mentioned there either, although they do make some improvements, there are also some problems.
A better way would be a different operating system design, although without that, you can still improve it on Linux. I think putting secrets in the message bus is not really the way to do sandboxing properly, and I think there should not be a global message bus (it should be specific to a program; if the program is properly sandboxed it can be limited what it can access, and possibly they can be declared by the use of environment variables, although).
There are also problems with the existing sandboxing systems; e.g. some do not work properly with character sets and might not support such things as: popen, command-line arguments of the program to restrict which files can be read/written, etc.
For security for programs running on the same computer communicating with each other while they are running, cryptographic algorithms are probaly not the way to do it; the operating system should handle the security to prevent programs from seeing and/or tampering with something that it is not supposed to do, so that the communication between programs is prevented unless it is configured to allow it.
For the data format, I might use DER (or SDER for the fields that are not required to be in canonical form, since canonical form does not matter for all fields but for some it might matter).
(The implementation would prevent messages from being sent to or received from whoever it is not supposed to be allowed to do, by checking the permissions and/or by just blocking access, forwarding the messages to proxies that might modify and/or log them, etc; such things can potentially make the system more versatile.)
So everyone has wanted "year of the Linux desktop" for a while. This year, since Microsoft has decided to call open season on their own feet and Valve has taken a break from swimming in their money pool to make sure absolutely any piece of software ever written can run on Linux, it looks like this might actually be happening. I am seeing a massive influx of new users, driven by distros like Cachy, Nobara, Bazzite. A lot of them don't have previous Linux experience and are generally not the most technically savvy users.
This absolutely terrifies me. Linux desktop security is, to put it politely, nonexistant. And the culture that goes with Linux desktop users just makes things worse, there's still a lot of BOFH gatekeeping going on, laughing at the new users when they inevitably mess something up and worst of all, completely refusing to admit that the Linux desktop has security issues. Whenever a new user asks what antivirus they should run, they are usually met with derision and ridicule, because the (oldschool) Linux users genuinely think their computers are somehow immune and can never be hacked.
The first cybercriminals to put some development effort into Linux ransomware/stealers are going to wreak havoc and a lot of people are going to be in for a rude awakening. The D-Bus issue with secrets in the article is just one of many many many ways in which Linux desktops are insecure by design.
There are of course distros out there that take security seriously, but we are not really seeing new users migrating to Qubes en masse.
Edit: not calling out the distros above in particular, all 3 are doing very good work and are not really any worse in security than most other distros.
>Back when I was writing xdg-desktop-portal-hyprland, I had to use a few dbus protocols (xdg portals run on dbus) to implement some of the communication. If we go to the portal documentation, we can find the protocols.
>[...]
>None of the apps, I repeat, fucking none followed the spec. [...]
>Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".
Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.
In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.
> It is not surprising the the properties would not be called the same.
It is a bit surprising that xdg-desktop-portal has two very similar APIs that differ in non-obvious and seemingly-arbitrary ways. I was also a bit confused about how the two APIs correspond (or don’t) when I first read their documentation.
92 comments
[ 5.2 ms ] story [ 86.3 ms ] threadWhy not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.
You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.
Those would have been a great starting point as well! But maybe we'll see them later.
On top of that, there's adverse selection here. Who gives up thousands of hours to work on some obscure corner of the Linux desktop? People with quite unusual thought processes.
It's just politics, really.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Etc. Etc.
No, Linux desktop is just an opportunity for a bunch of special snowflakes to enact their "vision", force their niche requirements on other 99.999% of users or create fiefdoms, where they can feel good and safe.
Reinvent what wheel exactly?
D-Bus can't read your mind (yet) and as such it can't generate an API for you, you still need to design a protocol, it's just that it's on top of D-Bus with certain quirks and restrictions.
Doing the same over UDS in 2025 isn't any more work and doesn't have any negative impact on end users. There's nothing unique about D-Bus from a usability standpoint that can't be done with a service listening over UDS.
This is equivalent to saying that you're reinventing the wheel by not using HTTP as a transport.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Maybe you should look at Varlink. The systemd backed D-Bus alternative. It uses JSON.
Regarding secrets management:
My password manager's protocol is handled using exec and command line arguments. Arbitrary applications can ask for passwords, but they won't get them. They won't read them from disk.
The design of the gnome keyring isn't great, but I actually don't think the protocol matters much in this case.
That when you can open a basic X11 application like xeyes or xterm, you can open any X11 application.
D-bus breaks this.
And it makes my Linux system feel like yet another case of "microservice failure".
That's not a surprise. The author of systemd, for instance, is working for Microsoft. Suddenly all those changes to the Linux ecosystem make a lot of sense. It became a corporate commodity, from A to Z. And when that is your objective, it kind of makes sense to have a unified system, even if it is crap.
Well, TIL. Looks like the default GUI for that is `seahorse`, so let's see what I've got on a relatively fresh installation... Looks like mostly Chromium stuff where there's a key that unlocks something more application-specific (e.g. for Discord) and an access token for my JetBrains account.
So no plaintext passwords per se, but now I wonder what a malicious app might uncover if it pursued the local Chromium stuff.
He didn't barge in guns blazing proclaiming "pip is a disgrace" and "it's a fuckin joke". He wrote a tool that was much better and encourage others to try it. Within a year or so, it snowballed into an unstoppable change.
This project currently has a bunch of C++ files, no docs, no tests, no roadmap on how it might replace d-bus, nothing. And as another commenter pointed out, starting a new system service in 2025, yelling about security, and doing this in an unsafe language doesn't inspire confidence.
Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with talking like this, but if you seriosly want to bring a wide community on board (without which the entire thing is a non-starter), look to Charlie instead.
Oh, and also, if you think D-Bus is bad, consider yourself lucky you didn't need to use the thing it replaced - CORBA.
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
(Or perhaps even COM)
Considering a sizeable part of Wayland's low-level stuff is written by Drew back in the day, vaxry won't touch anything written by Drew.
This "protocol" effort is to further decouple Hyprland from Wayland infrastructure.
Like everything, this effort is again driven by ego and spite.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
Holy shit. I knew conceptually that this was the case but never really took the time to consider the implications.
Pretty much whenever you unlock your keyring all your secrets are accessible by any software that can connect to the bus... How is this acceptable? Are we just supposed to run everything as Flatpak?
Turns out, that's every application, every few minutes, many of them multiple times. Applications like having access to things like refresh tokens so they can download your email, or discover passwords for offering autofill for a website.
I'd welcome many improvements to the Linux status quo, but applications not needing to ask before accessing the bus is the only reason it's usable in the first place.
I have never heard of D-Bus until today.
Maybe it should be treated better, not rebooting it every couple of times.
The problem is naturally the Linux desktop fragmentation that hinders a proper full stack approach to application development.
What works for GNOME is useless for KDE, and what works for KDE is useless for XFCE, which is ignored by Sway and so forth.
This will no doubt be used by many people who use Hyprland and I really don't think Vaxry cares about anything else. He's a college kid from Poland who now is getting enough donations he probably will never have to work for someone else if he doesn't want to, and can just continue developing his own ecosystem.
It will be interesting to see how it treats symlinks in this case. Or specifically, will this idea break completely for nixos or not.
SystemD -> SVCHost.exe
Iproute 2 -> You like netsh.exe?
Gnome 3, 4 -> Windows 8 wannabe
Mono -> C# road building path
GConf -> Windows Registry; heck, dconf-editor and gconf-editor look really close.
Can't wait for MMC.exe and GPO editing under Gnome.
I dunno man. Emacs is awesome.
A better way would be a different operating system design, although without that, you can still improve it on Linux. I think putting secrets in the message bus is not really the way to do sandboxing properly, and I think there should not be a global message bus (it should be specific to a program; if the program is properly sandboxed it can be limited what it can access, and possibly they can be declared by the use of environment variables, although).
There are also problems with the existing sandboxing systems; e.g. some do not work properly with character sets and might not support such things as: popen, command-line arguments of the program to restrict which files can be read/written, etc.
For security for programs running on the same computer communicating with each other while they are running, cryptographic algorithms are probaly not the way to do it; the operating system should handle the security to prevent programs from seeing and/or tampering with something that it is not supposed to do, so that the communication between programs is prevented unless it is configured to allow it.
For the data format, I might use DER (or SDER for the fields that are not required to be in canonical form, since canonical form does not matter for all fields but for some it might matter).
(The implementation would prevent messages from being sent to or received from whoever it is not supposed to be allowed to do, by checking the permissions and/or by just blocking access, forwarding the messages to proxies that might modify and/or log them, etc; such things can potentially make the system more versatile.)
This absolutely terrifies me. Linux desktop security is, to put it politely, nonexistant. And the culture that goes with Linux desktop users just makes things worse, there's still a lot of BOFH gatekeeping going on, laughing at the new users when they inevitably mess something up and worst of all, completely refusing to admit that the Linux desktop has security issues. Whenever a new user asks what antivirus they should run, they are usually met with derision and ridicule, because the (oldschool) Linux users genuinely think their computers are somehow immune and can never be hacked.
The first cybercriminals to put some development effort into Linux ransomware/stealers are going to wreak havoc and a lot of people are going to be in for a rude awakening. The D-Bus issue with secrets in the article is just one of many many many ways in which Linux desktops are insecure by design.
There are of course distros out there that take security seriously, but we are not really seeing new users migrating to Qubes en masse.
Edit: not calling out the distros above in particular, all 3 are doing very good work and are not really any worse in security than most other distros.
>[...]
>None of the apps, I repeat, fucking none followed the spec. [...]
>Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".
Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.
In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.
[1]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...
[2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...
[3]: https://flatpak.github.io/xdg-desktop-portal/docs/
It is a bit surprising that xdg-desktop-portal has two very similar APIs that differ in non-obvious and seemingly-arbitrary ways. I was also a bit confused about how the two APIs correspond (or don’t) when I first read their documentation.