5 ms·

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.

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

shevy-java 10mo ago
How does it work exactly? I mean, the premise here is: "it f*cking works" Can we objectify this claim made here?
antiloper 10mo ago
> Make clients store a cookie or something and only reply if they prove ownership of it Unix domain socket authentication is stronger and doesn't require storing cookies on the client side. > what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch. > I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.) Then don't use it? Secure defaults matter for most users. > Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh. Find the *kwargs here: https://wayland.app/protocols/xdg-shell https://wayland.app/protocols/xdg-shell Etc. etc. This isn't the 90s anymore.
- AshamedCaptain 10mo ago
  > Unix domain socket authentication is stronger and doesn't require storing cookies on the client side. And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands. > Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch. In which case they do not connect to the same D-Bus "bus", and the problem is again non-existent. See how flatpak sandoxing does it. > Then don't use it? Secure defaults matter for most users. Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about. In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage... > Find the *kwargs here: https://wayland.app/protocols/xdg-shell https://wayland.app/protocols/xdg-shell Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
  - torginus 10mo ago
    Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff. The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
  - jchw 10mo ago
    > And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands. I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy. > In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage... And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.) > Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself... That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.) I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
senko 10mo ago
> Do you hate a{sv}? If you propose JSON as alternative, Obviously, the components should talk using MCP.
- skissane 10mo ago
  You may be joking but I think seriously that may be a decent idea. The universal RPC/automation mechanism which everybody implements-whatever its warts may be-is superior to a better-designed one which few actually end up supporting. You don’t need an LLM to call MCP tools, there’s nothing stopping you from calling MCP tools from any programming language.
blablabla123 10mo ago
This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this? The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus. Also I'm puzzled that Polkit hasn't been mentioned even once.
- vanviegen 10mo ago
  > The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
  - LtWorf 10mo ago
    There's sandbox escapes daily since decades. It doesn't work.
    - akimbostrawman 10mo ago
      >There's lock picking daily since centuries. It doesn't work
      - LtWorf 10mo ago
        It takes time to pick one lock and twice as much to pick two. It takes the same time to escape 1 or 10000000 sandboxes.
        gf000 10mo ago
        That's only somewhat true if we are talking about the same sandbox nested (which would be quite dumb to do). Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.
torginus 10mo ago
I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around. And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other. I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.
- seba_dos1 10mo ago
  > hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
smaudet 10mo ago
I've never had much luck with it either. A lot of the same pain points as the author. As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing... Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus. If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing. The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally... Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...
agumonkey 10mo ago
I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.
themafia 10mo ago
d-bus often fails to work properly, at least on my machine, where systemd is not in use. it already annoys me. an alternative would be welcome.
Lammy 10mo ago
> Does it miss a spec? Write one. FreeDesktop-dot-Org would not accept one from the author if he did: https://blog.vaxry.net/articles/2024-fdo-and-redhat https://blog.vaxry.net/articles/2024-fdo-and-redhat https://blog.vaxry.net/articles/2024-fdo-and-redhat2 https://blog.vaxry.net/articles/2024-fdo-and-redhat2
Hizonner 10mo ago
I don't recall asking for any "bus" in the first place.
javier2 10mo ago
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...
wolvesechoes 10mo ago
> 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.
Arch-TK 10mo ago
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.

shevy-java 10mo ago

How does it work exactly? I mean, the premise here is: "it f*cking works" Can we objectify this claim made here?

antiloper 10mo ago

> Make clients store a cookie or something and only reply if they prove ownership of it Unix domain socket authentication is stronger and doesn't require storing cookies on the client side. > what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch. > I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.) Then don't use it? Secure defaults matter for most users. > Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh. Find the *kwargs here: https://wayland.app/protocols/xdg-shell https://wayland.app/protocols/xdg-shell Etc. etc. This isn't the 90s anymore.

AshamedCaptain 10mo ago
> Unix domain socket authentication is stronger and doesn't require storing cookies on the client side. And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands. > Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch. In which case they do not connect to the same D-Bus "bus", and the problem is again non-existent. See how flatpak sandoxing does it. > Then don't use it? Secure defaults matter for most users. Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about. In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage... > Find the *kwargs here: https://wayland.app/protocols/xdg-shell https://wayland.app/protocols/xdg-shell Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
- torginus 10mo ago
  Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff. The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
- jchw 10mo ago
  > And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands. I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy. > In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage... And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.) > Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself... That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.) I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)

senko 10mo ago

> Do you hate a{sv}? If you propose JSON as alternative, Obviously, the components should talk using MCP.

skissane 10mo ago
You may be joking but I think seriously that may be a decent idea. The universal RPC/automation mechanism which everybody implements-whatever its warts may be-is superior to a better-designed one which few actually end up supporting. You don’t need an LLM to call MCP tools, there’s nothing stopping you from calling MCP tools from any programming language.

blablabla123 10mo ago

This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this? The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus. Also I'm puzzled that Polkit hasn't been mentioned even once.

vanviegen 10mo ago
> The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
- LtWorf 10mo ago
  There's sandbox escapes daily since decades. It doesn't work.
  - akimbostrawman 10mo ago
    >There's lock picking daily since centuries. It doesn't work
    - LtWorf 10mo ago
      It takes time to pick one lock and twice as much to pick two. It takes the same time to escape 1 or 10000000 sandboxes.
      - gf000 10mo ago
        That's only somewhat true if we are talking about the same sandbox nested (which would be quite dumb to do). Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.

torginus 10mo ago

I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around. And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other. I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.

seba_dos1 10mo ago
> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.

smaudet 10mo ago

I've never had much luck with it either. A lot of the same pain points as the author. As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing... Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus. If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing. The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally... Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...

agumonkey 10mo ago

I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.

themafia 10mo ago

d-bus often fails to work properly, at least on my machine, where systemd is not in use. it already annoys me. an alternative would be welcome.

Lammy 10mo ago

> Does it miss a spec? Write one. FreeDesktop-dot-Org would not accept one from the author if he did: https://blog.vaxry.net/articles/2024-fdo-and-redhat https://blog.vaxry.net/articles/2024-fdo-and-redhat https://blog.vaxry.net/articles/2024-fdo-and-redhat2 https://blog.vaxry.net/articles/2024-fdo-and-redhat2

Hizonner 10mo ago

I don't recall asking for any "bus" in the first place.

javier2 10mo ago

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

wolvesechoes 10mo ago

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

Arch-TK 10mo ago

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.