Monday March 16 2026

Hacker Times

Problems with D-Bus on the Linux desktop

Discussion

There has been quite a bunch of interest in this post, I've added a FAQ section at the bottom.
I will be adding stuff there if more FAQs pop up. Thanks!

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.

As a service, D-Bus is incredibly handy and useful, and overall, I believe the idea should absolutely be used by more apps. However, the implementation... oh boy.

What is D-Bus?

Everyone has heard about D-Bus, but what is it, actually?

D-Bus' idea is pretty simple: let applications, services and other things expose methods or properties in a way that other apps can find them in one place, on the bus.

Let's say we have a service that monitors the weather. Instead of each app knowing how to talk to each weather service, or even worse, implementing one itself, it can connect to the bus, and see if any service on the system exposes some weather API, then use it to get weather.

Great, right? And yeah, the idea is wonderful.

What went wrong?

D-Bus is a lenient, unorganized and forgiving bus. Those three add to one of the biggest, fundamental, and conceptual blunders to any protocol, language or system.

The most important blunders are:

Objects on the bus can register whatever they want.
Objects on the bus can call whatever they want, however they want, whenever they want.
The protocol allows and even in a sense incentivises vendor-specific unchecked garbage.

What this means in practice is the definition of "Garbage in, garbage out".

D-Bus standards, part 1

Okay, apps need to communicate, right? Well, in some way right? Where do we find the way?

Uhh... somewhere online, probably. Nobody actually knows because some of them are here, some there, many are unfinished, unreadable, or convoluted garbage docs, and no client follows them anyways.

Let's take a look at some gems. These are actual docs

Truly secure. source

I guess service implementors should learn telepathy. source

So is it a draft or widely used? source 1 and source 2

D-Bus standards are a mess. And that's if we assume that implementors on both sides actually follow them (they often don't, as we will learn in a moment...)

D-Bus standards, part 2

Okay, let's say we have a standard and we understand it. Great! Now...

nobody gives a shit, literally. Even if you read a spec, nothing, literally nothing, guides, ensures, or helps you stick to it. NOTHING. You send anonymous calls with whatever bullshit you want to throw in.

Let me tell you a story...

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.

Great! So I implemented it. It worked more-or-less. Then, I implemented restore tokens, which allow the app to restore its previously saved share configuration. And here, dbus falls apart.

None of the apps, I repeat, fucking none followed the spec. I wrote a spec-compliant mechanism and nothing fucking used it. Why? Simple, they all used a different spec, which came out of fucking nowhere, I legit couldn't find a single doc with it. What I ended up doing was I looked at KDE which already had an impl and mimic'd that.

What the actual fuck. "Spec" my ass.

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

D-Bus standards, part 3

Let me just say one word: variants. What in the actual, everloving fuck? Half of D-Bus protocols have either this BS, or some "a{sv}" (array of string + variant) passed somewhere.

Putting something like this, even allowing that in a core spec should be subject to a permanent ban from creating software. What this allows, and even incentivises, is for apps to send random shit over the wire and hope the other side understands it. (see the example above in part 2, prime dbus) This has been tried many times, most notably in X with atoms, and it has time and time again proven to only bring disaster.

D-Bus standards, part 4

Ever heard of permissions? Neither have D-Bus developers. D-Bus is as insecure as it gets. Everybody sees everything and calls whatever. If the app doesn't have a specific security mechanism, cowabunga it is. Furthermore, there is no such thing as a "rejection" in a universal sense. Either the protocol invents its own "rejection" or just... something happens, god knows what, actually.

This is one of the prime reasons flatpak apps can not see your session bus.

D-Bus standards, part 5

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?

No. No, they aren't. These secrets may be encrypted on disk, which technically prevents them from being stolen if your laptop is stolen. If you just cringed at that because disk encryption has been a thing for 20 years now or so, you're not alone.

However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked. No, this is not a fucking joke. Once you input that password, any app can just read all of them without you noticing.

This is the real stance of GNOME developers on the issue:

source

Honestly, I am at a loss of words as to how to describe this without being extremely rude.

Security so good microsoft might steal it for their recall.

Enough is enough

I've had enough of D-Bus in my apps. I would greatly benefit from a session (and later, system) bus for my ecosystem, but I will not stand the absolute shitfest that D-Bus is.

That is why, I've decided to take matters into my own hands. I am writing a new bus. From the ground up, with zero copying, interop, or other recognition of D-Bus. There are so many stupid ideas crammed into D-Bus that I do not wish to have any of them poison my own.

XKCD 927

A lot of people quote this xkcd comic for each new implementation. However, this is not exactly the same.

For example, with wayland, when you switch, you abandon X. You cannot run an X11 session together with a wayland one, simply not how it works.

You can, however, run two session buses. Or three. Or 17. Nothing stops you. That's why gradual migration is absolutely possible. Sure, these buses can't talk to each other, but you can also create a proxy client that can "translate" dbus APIs into new ones.

Wire

The first thing I focused on was hyprwire. I needed a wire protocol anyways for hypr* stuff like hyprlauncher, hyprpaper, etc.

The wire protocol is inspired by how Wayland decided to handle things. Its most important strengths are:

consistency: the wire itself enforces types and message arguments. No "a{sv}", no "just send something lol"
simplicity: the wire protocol is fast and simple. Nobody needs complicated struct types, these just add annoyances.
speed: fast handshakes and protocol exchanges, connections are estabilished very quickly.

Hyprwire is already used for IPC in hyprpaper, hyprlauncher and parts of hyprctl, and has been serving us well.

Bus

The bus is called hyprtavern, as it is not exactly what D-Bus is, but it's more like a tavern.

Apps register objects on the bus, which have exposed protocols and key properties defined by the protocols. These objects can be discovered by other apps connecting to the bus.

In a sense, hyprtavern acts like a tavern, where each app is a client, that can advertise the languages they speak, but also go up to someone else and strike up a conversation if they have a language in common.

Some overall improvements over D-Bus, in no particular order:

Permissions: baked in, in-spec permissions. Suitable for exposing to sandboxed apps by default.
Strict protocols: don't know the language? Don't poison the wire. Worth noting this does not stop you from making your own extensions, it just enforces you stay in-spec.
Simplified API: D-Bus has a lot of stupid ideas (shoutout broadcast) that we intentionally do not inherit.
Way better defaults: The core spec also includes a few things that are optional (and dumb) in D-Bus like an actually secure kv store.

Kv

With relation to the Secrets API discussed a bit above, I wanted to mention kv.

hyprtavern-kv is the default implementation of the core protocol for a kv store. A kv store is a "key-value" store, which means apps register values for "keys", e.g. "user_secret_key = password".

This is essentially what D-Bus Secrets API does, but instead of being a security joke, it's actually secure by-design.

Any app can register secrets, which only it can read back. Secrets cannot be enumerated. This means that when "/usr/bin/firefox" sets a "passwords:superwebsite.com = animebooba", an app called "~/Downloads/totally_legit.sh" can not see the value, or the key, or that firefox even set anything.

This also (will) work with Flatpak, Snap and AppImage applications by additionally using their Flatpak ID, Snap ID or AppImage path respectively. This is not implemented, but planned.

This kv store is always encrypted, but a default password can be used which means it will be unlocked by default and the store file can be trivially decrypted. The difference is that if you set a password here, it will actually be secure, even if an app with access to the bus tries to steal all of the secrets.

Additionally, this protocol is core. It must be implemented by the bus, which means all apps can benefit from a secure secret storage.

Is hyprtavern ready?

No, absolutely not. I started work on it just recently, and I still need to cook a bit. It's coming though, really!

I hope to get it widely used within hypr* by 0.54 of hyprland (that is the release after the upcoming 0.53).

Do I expect adoption?

No, definitely not at the beginning. But, it's an easier transition than X11 -> Wayland, and I didn't expect Hyprland to be widely adopted either, but here we are.

Time will tell. All I can say is that it is just better than D-Bus.

An important part of adoption will probably be bindings to other languages. The libraries are all in C++, but since they aren't very big (by design), making Rust / Go / Python bindings shouldn't be hard for someone experienced with those languages.

The wire format is also simple and open, so you could also write a Memory-Safe™ libhyprwire in Rust for example.

Closer

D-Bus has been an annoyance of mine for years now, but I finally have the ecosystem and resources to write something to replace it.

Let's hope we can make the userspace a bit nicer to work with :)

Addendum

This post is quickly gathering attention so I will answer some FAQs:

Reinventing the wheel won't help

The wheel is fundamentally broken. D-Bus is unfixable due to its core principles being terrible.

Where docs?

As I've said, hyprtavern is a heavy WIP. Once it is ready for app developers, which I hope to be done with within a month, I will write extensive docs about both the wire protocol (so that you can implement it yourself if you don't like libhyprwire) and the tavern itself.

Why not use wayland?

I've implemented a few improvements to hyprwire for bus usage (e.g. array types), and additionally wayland is not meant to be a generic IPC protocol. Connecting is restricted to sockets and WAYLAND_DISPLAY, for example. One could fork it, but at this point, it's better to write your own impl.

Can we add dbus-compatibility translators?

Yes. You can write a for example hyprtavern-dbus-notification-proxy which sets up a dbus notification service and exposes the events as an appropriate tavern protocol. Worth noting of course such a protocol doesn't exist yet as I am working on the core spec atm. There will be though.

Why C++ and not memory safe rust?

Because I am a C++ dev. You are free to reimplement the bus / wire in Rust. You are also free to write bindings. BSD-3.

Hyprland (and related) historically have had less and less memory issues over time thanks to our shift to hyprutils and very common (almost religious) refcounting practices. However, nothing's stopping you from rewriting things in Rust.

The portal docs are actually correct, you just were reading the wrong ones

Yes, a person on hackernews named mahkoh pointed this out (thanks!). This doesn't change the fact that:

the docs are poorly separated, such that I could not easily find that information.
the names for things for app -> portal and portal -> portal impl are different (wtf, what are you guys smoking?)
the website he links didn't exist (IIRC at all, or at least in its current state, IIRC it was a mostly blank page) back when I was impl'ing it.
most importantly: DBus allows you to do whatever while a real protocol would enforce the types outright and forbid invalid usage.

Fragmentation, gnome and kde have different needs

Hasn't stopped them from both using D-Bus to this day. Apparently you can have one bus for both.

What about symlinks in paths?

Just resolve them. For chrooted apps, both Linux and BSD provide a way to get root from pid. I've been told it will break on Nix, but I will let the Nix folks figure this one out as I don't use it.

Where can we follow development or see the protocol?

Hyprwire's wire format is not yet documented, but it's quite simple. Docs will be written by me once tavern's ready.

For the core tavern protocol spec WIP, please see here. Please note it's of course a WIP so breaking changes do happen as I try to accomodate more usecases. Feedback is welcome though, feel free to leave feedback if you're an app or DE developer with a specific usecase in mind.

What about LD_PRELOAD?

Look, I realize in the current UNIX space it's impossible to 100% verify regular system apps, but there are two improvements here.

Firstly, we raise the barrier to steal secrets significantly. An attacker now needs to know what app they are inside, what secrets that app may store (apps themselves can't enumerate either). Additionally, it needs to do more than just a single query, which becomes more detectable. It's always better to at least know you've been hacked.

Two, this is a requirement for sandboxed apps to be able to interact with the tavern. The entire idea of the security model is so that flatpak apps don't need to be restricted from using the session bus anymore and we don't need a proxy (like xdp).

seba_dos1•3 months ago

Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.

  $ ls -1 /usr/lib/qt6/plugins/kf6/parts | wc -l
  20

AshamedCaptain•3 months ago

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

Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example).

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

The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?

If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).

Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .

If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?

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

Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.

jchw•3 months ago

> Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example).

I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths. You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want. The policy would obviously vary strongly depending on the system, but if you were dealing with a secure booted system with dm-verity, or something similar, well then this mechanism should be fairly watertight. It's not really the end of the world if there are systems with different security characteristics here.

You can really get creative.

(It is worth noting, though, that this could be bypassed various ways trivially, like with LD_PRELOAD, so to be a true security boundary it would need more thought. Still, this could definitely be made improved numerous ways.)

> The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?

Well, the obvious initial benefit is the same thing that DPAPI has had for ages, which is that it's encrypted on-disk. Of course that's good because it minimizes the number of components that will see the raw secret and ensures that even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.

An additional case worth considering is when the home folder is stored elsewhere over a network filesystem, as in some more enterprise use cases.

> If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).

It would be ill-advised to have each application deal with how to encrypt user data. They can store keymatter in the keyring instead of the data itself if they want to handle storage themselves. (I'm pretty sure this is actually being done in some use cases.)

> Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .

That page exists to explain why they don't bother, but part of that is that there just isn't an option. If there actually was an option, well, it would be different.

> If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?

The threat vector is whatever you want it to be, there are plenty of things this could be useful for. The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either. This is probably in part because on Linux most of the programs you run are inherently somewhat vetted by your distribution and considered "trusted" (even if they are subject to MAC like SELinux or AppArmor, like in SuSE) so adding a sandbox feels somewhat superfluous and may be inconvenient (i.e. file access in Bottles is a good example.) But, even in a world where all desktop apps are running in bubblewrap, it's still nice to have extra layers of defense that compliment each other. And even if something or someone does manage to access your decrypted home folder data, it's nice if the most sensitive bits are protected.

> Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.

The reason why people don't bother doing this (in my estimation) is because DBus is demoralizing to work on. DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.

And therein lies the rub: if you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.

AshamedCaptain•3 months ago

> I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths.

Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.

> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.

Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.

> hat even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.

I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.

I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is. You'd just put the data in the "more secure" storage to begin with.

What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.

You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?

> It would be ill-advised to have each application deal with how to encrypt user data.

Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).

> The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either.

In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.

> DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.

This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.

> you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.

I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.

Loading replies...

jchw•3 months ago

> Because you do not get it: this is not Android. There is no fixed UIDs.

Uhhh... I didn't say anything about fixed UIDs.

> There is no fixed absolute paths.

There is if your distribution says there is.

> The binaries are not always root-owned.

They are if your distribution says they are.

> There is no central signing authority (thank god!).

I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.

But anyway. There is if your distribution has one.

> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.

There is if your distribution makes there a way to validate something from the PID.

The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.

Immutable distros exist right now.

> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.

This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.

> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.

Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.

> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.

That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".

Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.

> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?

sigh

You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.

Checking my kdewallet, I can see the following applications:

- KRDC

- Remmina

- KRDP

- Chromium

- krfb

- xdg-desktop-portal

... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.

Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.

> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).

Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)

And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.

> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.

It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.

> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.

Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.

But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.

(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)

Loading replies...

AshamedCaptain•3 months ago

> There is if your distribution says there is.

You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do (that's the entire point), the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.

If flatpak or your distribution suddenly start requiring _root_ so that users can run programs that do not really require root, this not only would be a net security degradation rather than improvement, it would prevent me from using that distribution altogether. And yes, these programs need access to the desktop, the theming service, accessibility, input management, etc. for obvious reasons.

This is why even the current method is superior to anything you are proposing here, and the SCM_CREDENTIALS stuff just does not rightly fit in the Linux desktop model.

> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye

ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.

Go and check how much love you are going to get if you start asking around for people to sign their own binaries to run them in their machine, to implement a sandboxing mechanism that there are a million other, way less intrusive ways to implement.

> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.

It doesn't really matter. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.

> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.

A problem I fully acknowledge. But how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API (more or less what Wayland supposedly did to X11), and this is a decades-long task _at best_. A different IPC system doesn't really help, and may even delay this!.

> Do you know what "principle of least privilege" is? M

Irrelevant when my point is that I want _my_ privileged process to manage the password keyring itself.

> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.

The entire raison-d'être for KWallet was to store AND SHARE passwords amongst programs, as a glorified netrc replacement. The "secure" storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it. As you are aware of, KWallet and gnome-keyring have never provided any level of actual secure storage.

> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.

why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app store? Why would user want to backup the passwords but not the private app documents?

"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."

I mean, from your description, you want KWallet to provide protection so that say the mail client cannot access the browser passwords (something I already disagree with). But don't you also want, in this containerized world, for the mail client to NOT be able to read your browser's history, for example? If you already provide secure, containerized storage for apps, I fail to see any specific distinction between "private app data" and "private app secret" (I would still make the distinction if it was "shared"). You'd want your history to be protected (from other programs) as much as any website password.

I do not even know why you bring up the word "regulation" in here.

> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd

This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.

> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.

You keep framing this as if we were not improving the Linux desktop too, which just shows your bias.

My point: Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.