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