D-Bus 由 GNOME 团队在约二十年前推出。相较于已有四十载历史的 X Window 系统，这款仅诞生二十年的软件竟同样糟糕得令人震惊。
作为服务层，D-Bus 确实极其便捷实用，我认为其核心理念理应被更多应用所采纳。然而具体实现…天啊。
何为 D-Bus？
人人皆闻 D-Bus，但它究竟是什么？
D-Bus 的理念相当简单：让应用程序、服务及其他“实体”以某种方式暴露方法或属性，使其他应用能在总线(bus)上集中发现这些资源。
假设存在一个气象监控服务。应用程序无需各自掌握与气象服务的通信方式，更不必自行实现服务——它们只需连接总线，即可查询系统中是否存在提供气象API的服务，进而调用获取天气数据。
听起来很棒，对吧？没错，这个理念确实精妙。
问题出在哪里？
D-Bus 是一个宽松、无序且宽容的总线。这三点共同构成了任何协议、语言或系统中最严重、最根本、最致命的概念性缺陷。
最关键的缺陷在于：
- 总线上的对象可随意注册任意内容
- 总线上的对象可随时随地以任意方式调用任意内容
- 协议不仅允许，甚至某种程度上鼓励厂商制造未经检查的专有垃圾。
这在实践中正是**“垃圾输入，垃圾输出”**的生动诠释。
D-Bus标准(上篇)
应用程序需要通信，对吧？总得有某种方式吧？该去哪里寻找？
呃…大概在网上某个角落吧。其实没人真正知道，因为文档散落各处，有的在此，有的在彼，多数要么未完成、难以理解，要么就是混乱的垃圾文档，而且客户端根本不会遵循它们。
让我们看看这些“精品”。这些是真实文档
真正安全。源代码
看来服务实现者该学学心灵感应了。源代码
D-Bus标准简直一团糟。这还是假设双方实现者都遵守规范的前提下(实际上他们经常不遵守，稍后我们会看到…)
D-Bus标准续篇
假设我们拥有明确标准且理解透彻。很好！但现在…
根本没人会在乎，字面意义上的不在乎。即便你研读了规范文档，没有任何东西——真的没有任何东西——能引导、保障或帮助你遵守规范。完全没有。你可以随心所欲地发送匿名调用，塞进任何垃圾数据。
让我讲个故事…
当年编写 xdg-desktop-portal-hyprland 时，我不得不使用几个 D-Bus 协议(XDG 门户运行在 D-Bus 上)来实现部分通信功能。查阅门户文档就能找到这些协议。
太棒了！于是我照着实现了。功能基本正常。随后我又实现了 恢复令牌 功能，让应用能恢复先前保存的共享配置。结果D-Bus彻底崩溃了。
没有任何应用——我再说一遍，他妈的没有一个遵循规范。我写了符合规范的机制，结果他妈的没人用。为什么？很简单，它们全都使用了另一套规范，这套规范简直是他妈的凭空出现，我真的找不到任何相关文档。最终我只能参考KDE的实现方案进行仿制。
这他妈算什么？“规范”个屁。
冷知识：**这种情况至今未改！**规范明明规定SelectSources和Start应使用“restore_token”字符串属性，但所有应用都置之不理，反而在“options”里用“restore_data”。
D-Bus标准之三
只需说一个词：变体。这到底他妈的什么鬼？半数D-Bus协议要么包含这种垃圾，要么在某处传递“a{sv}”(字符串数组+变体)。
在核心规范中允许这种东西的存在，就该永久禁止相关人员开发软件。这种设计不仅纵容，甚至鼓励应用程序在网络中发送随机数据，指望接收方能理解(参见第二部分 prime dbus 的示例)。类似尝试在 X Window 系统使用原子参数时已屡见不鲜，而历史反复证明这只会招致灾难。
D-Bus 标准之四
听说过权限机制吗？D-Bus开发者显然也不懂。D-Bus的安全性堪称灾难——所有对象对所有人可见，任何调用都无限制。若应用缺乏专属安全机制，后果不堪设想。更糟的是，协议中根本不存在普适意义上的“拒绝”机制。要么自行发明“拒绝”机制，要么…就发生某些不可预知的事情，天知道会怎样。
这是Flatpak应用程序无法访问您的会话总线的主要原因之一。
D-Bus标准系列之五
您是否见过kwallet或gnome-keyring？没错，就是这些东西。它们本应作为签名密钥、密码等信息的“秘密存储库”。这些存储库可通过密码保护，这意味着它们是安全的…对吗？
不。不，并非如此。这些密钥可能在磁盘上进行了加密，从技术上讲，这能防止笔记本被盗时密钥遭窃。若你对此感到不适——毕竟磁盘加密技术已有二十年历史了——你并非唯一。
然而最糟糕的是：只要存储库处于解锁状态，总线上的任何应用都能读取所有密钥。不，这他妈不是玩笑。一旦你输入密码，任何应用都能悄无声息地读取所有密码。
以下是GNOME开发者对此问题的真实立场：
老实说，要描述这种情况而不显得极其粗鲁，我实在词穷。
安全性好到微软都想偷走用于召回系统。
忍无可忍
我受够了应用程序里的D-Bus。虽然我的生态系统确实需要会话总线(后期还需系统总线)，但我绝不能忍受D-Bus这种绝对的垃圾。
因此我决定亲自动手。正在从零构建全新总线，绝不借鉴D-Bus的任何代码、互操作性或设计理念。D-Bus里塞满了太多愚蠢的设计，我绝不愿让它们毒害自己的项目。
XKCD 927
许多人总爱用这幅xkcd漫画来比喻新方案的诞生。但实际情况并非完全相同。
以Wayland为例，切换系统时你必须放弃X。你无法同时运行X11会话和Wayland会话——这根本行不通。
但你可以同时运行两个会话总线。或者三个。甚至十七个。没有任何限制。正因如此，渐进式迁移完全可行。虽然这些总线无法直接通信，但你可以创建代理客户端，将dbus API“翻译”成新接口。
传输协议
我首先关注的是hyprwire。无论如何我都需要一个传输协议来支持hypr*系列工具，比如hyprlauncher、hyprpaper等。
该协议的设计灵感源自Wayland的实现思路，其核心优势在于：
- 一致性：协议本身强制类型检查与参数验证，杜绝“a{sv}”这类模糊定义，更不会出现“随便发点东西吧哈哈”的混乱局面
- 简洁性：协议快速轻量，无需复杂结构体类型，避免冗余操作
- 高效性：快速握手与协议交换机制，连接建立速度极快
Hyprwire 已应用于 hyprpaper、hyprlauncher 及 hyprctl 部分模块的进程间通信，表现优异。
总线
该总线命名为 hyprtavern，因其并非完全等同于 D-Bus，更像是一家酒馆。
应用程序在总线上注册对象，这些对象暴露协议并定义协议的关键属性。连接总线的其他应用程序可发现这些对象。
某种意义上，hyprtavern就像一家酒馆：每个应用程序都是客户，既能展示自己通晓的语言，也能主动与他人开启对话——只要双方语言相通。
相较于 D-Bus 的整体改进(无特定排序)：
- 权限机制：内置规范化权限体系，默认适用于沙盒化应用。
- 严格协议：不懂语言？请勿污染通信通道。需注意这并不妨碍自定义扩展，仅强制要求遵循规范。
- 简化API：刻意摒弃D-Bus诸多拙劣设计(如广播机制)。
- 更优默认配置：核心规范包含D-Bus可选(且低效)的特性，例如真正安全的键值存储。
键值存储
承接前文提及的密钥管理API，需特别说明键值存储机制。
hyprtavern-kv 是键值存储库的 核心 协议默认实现。键值存储库本质是“键值对”存储机制，应用程序通过注册“键”来存储值，例如“user_secret_key = password”。
这与 D-Bus Secrets API 的功能本质相同，但并非安全笑话——它从设计之初就具备安全性。
任何应用都能注册密钥，但仅限自身读取。密钥无法被枚举。这意味着当“/usr/bin/firefox”设置“passwords:superwebsite.com = animebooba”时，名为“~/Downloads/totally_legit.sh”的应用既无法查看该值，也无法获取密钥，甚至无法知晓firefox曾进行过设置。
此方案同样适用于Flatpak、Snap和AppImage应用程序，只需分别使用其Flatpak ID、Snap ID或AppImage路径即可。该功能尚未实现，但已列入计划。
此键值存储库始终处于加密状态，但默认密码可被使用，这意味着存储库默认处于解锁状态，存储文件可被轻易解密。区别在于：若在此处设置密码，即使有应用程序通过总线访问试图窃取所有密钥，该密码仍能确保安全。
此外，此协议属于核心功能。总线必须实现该协议，这意味着所有应用程序都能受益于安全的密钥存储。
Hyprtavern是否已就绪？
绝对没有。我刚着手开发不久，仍需进一步完善。但它确实即将问世！
我计划在hyprland 0.54版本(即即将发布的0.53之后的版本)中实现其在hypr*系列中的广泛应用。
是否期待普及？
初期肯定不会。但相较于X11→Wayland的迁移，这次过渡更为平缓——当初我也未曾预料Hyprland能获得广泛采用，如今却已成现实。
时间自会给出答案。我只能说它比D-Bus更胜一筹。
推广的关键可能在于其他语言的绑定实现。虽然库文件均采用C++编写，但因其设计之初就保持精简，对熟悉Rust/Go/Python的开发者而言，实现相应绑定并不困难。
其传输协议格式同样简单开放，例如完全可以基于Rust编写内存安全的libhyprwire库。
结语
多年来D-Bus始终令我困扰，如今终于具备生态与资源来打造替代方案。
愿我们能让用户空间变得更宜居 🙂
附录
本文迅速引发关注，现解答常见疑问：
重新发明轮子毫无意义
因为这个轮子本身就根本性地破损了。D-Bus因其糟糕的核心设计理念而无法修复。
文档何在？
如前所述，hyprtavern仍处于重度开发阶段。待其准备好迎接应用开发者(预计一个月内完成)，我将撰写详尽文档，涵盖通信协议(若您不喜欢libhyprwire可自行实现)及酒馆系统本身。
为何不用 Wayland？
我已在 hyprwire 中针对总线使用做了若干改进(如数组类型支持)，况且 Wayland 本身并非通用 IPC 协议。其连接方式仅限于套接字和 WAYLAND_DISPLAY 等机制。虽然可以分叉实现，但现阶段还是编写自有实现更合理。
能否添加DBus兼容转换器？
可以。例如编写hyprtavern-dbus-notification-proxy，该程序可设置DBus通知服务，并将事件转换为适配的酒馆协议。需注意当前核心规范尚未完成，但此类协议未来会实现。
为何选择C++而非内存安全的Rust？
因为我是C++开发者。您完全可以自由用Rust重构总线/传输层，也可自由编写绑定库。采用BSD-3.0许可。
Hyprland(及相关项目)历经多年演进，得益于转向hyprutils工具链及近乎宗教般严格的引用计数实践，内存问题已大幅减少。但这并不妨碍您用Rust重写现有代码。
门户文档其实是正确的，只是你读错了文档
没错，Hacker News上一位名为mahkoh的用户指出了这个问题(感谢！)。但这并不改变以下事实：
- 文档分类混乱，导致我难以快速找到相关信息
- 应用端→门户端与门户端→门户端的实现命名不统一(搞什么鬼，你们在抽什么？)
- 他链接的网站在我实现时根本不存在(至少记忆中是空白页面)。
- 最关键的是：DBus允许随意操作，而真正的协议会强制类型检查并禁止非法使用。
碎片化问题：GNOME和KDE需求不同
这并未阻止两者至今仍在使用D-Bus。显然单一总线可同时服务于两者。
路径中的符号链接如何处理？
直接解析即可。对于chroot环境下的应用，Linux和BSD都提供了通过进程ID获取root权限的机制。据说Nix系统会出现兼容问题，但我不使用Nix，就留给Nix团队去解决吧。
如何追踪开发进展或查看协议规范？
Hyprwire的传输格式尚未文档化，但结构相当简单。待酒馆系统就绪后，我将撰写相关文档。
酒馆核心协议规范(WIP)请参阅此处。请注意这是工作版本，为适配更多用例可能存在破坏性变更。欢迎反馈意见，若您是应用或桌面环境开发者且有具体用例需求，请随时提出建议。
LD_PRELOAD功能如何？
我明白在当前UNIX环境中无法100%验证常规系统应用，但这里有两项改进措施：
首先，我们大幅提高了窃取密钥的门槛。攻击者现在不仅需要知道自己身处哪个应用程序，还需了解该应用可能存储哪些密钥(应用本身也无法枚举)。此外，攻击者必须执行多次查询而非单次操作，这使得攻击行为更易被察觉。至少能察觉到自己遭到入侵总归是好事。
其次，这是沙盒化应用程序与系统服务层交互的必要条件。整个安全模型的设计初衷，正是为了使Flatpak应用程序无需再受限于会话总线，同时避免使用代理机制(如XDP)。
本文文字及图片出自 D-Bus is a disgrace to the Linux desktop
> 然而最糟糕的是：只要存储库处于解锁状态，巴士上的任何应用都能读取存储库中的所有密钥
>> GNOME项目方对这份漏洞报告持反对意见，因为根据其宣称的安全模型，未经信任的应用程序不得与密钥服务进行通信。
我要提醒所有犹豫不决的人：没错，GNOME确实由穿着全尺寸小丑鞋的丑角们运营。
考虑到Wayland诸多摩擦都打着安全旗号(“我们为什么要标准化键盘输入的拦截与发送？这不安全！”)，这尤其令人震惊。
其安全机制在于应用程序运行于沙箱环境(如Flatpak、snap)，仅能通过受限方式(如xdg-dbus-proxy)访问D-Bus、Wayland等系统接口。
所谓“阻力”在于Wayland开发者不愿让沙盒应用通过访问Wayland套接字来掌控整台机器。
试图在同一UNIX用户内隔离应用本质上无法实现，因为存在ptrace、LD_PRELOAD、/proc/$pid、.bashrc注入等手段。
作者必然知晓这些问题，毕竟文末LD_PRELOAD的注释已提及。在我看来，他提出的方案本质是安全靠模糊(在根本不安全的系统上堆砌障碍)。
没错，这完全是安全戏剧。程序甚至不被允许设置自己的图标，理由是这不够安全——我可不是在开玩笑。其逻辑大致是：万一恶意程序将自身命名为“firefox”，盗用火狐图标，然后诱骗你输入Gmail密码怎么办？
与此同时，恶意软件完全可以利用d-bus在不提示的情况下窃取所有密码，甚至读取所有文件——毕竟它是以你的用户ID运行的。
> 程序甚至不被允许设置自己的图标
在GNOME中。设置窗口图标存在规范协议，Wayland合成器会遵循该协议——它们认为为每个窗口配备自定义图标具有价值。GNOME认为同一程序的多个窗口使用不同图标会造成混淆，尤其考虑到这些图标在GNOME环境中仅能显示在Dock栏和Alt+Tab菜单中。但用户常将应用固定到Dock栏，导致同一应用的多个窗口无法在此处显示自定义图标。
> 与此同时，恶意软件甚至无需请求权限，就能通过d-bus获取所有密码，或读取所有文件——毕竟它是以你的用户ID运行的。
这种说法并不完全准确，因为这需要应用程序具备与密钥服务通信的权限(若使用Flatpak)
Linux桌面环境的沙盒化远未普及，而Flatpak的安全性堪称笑话[1][2]——除非近期有所改进。首先，沙盒化需由应用主动请求，因此若我制作恶意Flatpak，只需申请完整文件系统访问权限或d-bus权限即可。
[1]: https://flatkill.org/ [2]: https://hanako.codeberg.page/
> 首先，必须由应用程序主动请求沙箱化
你确定吗？我原以为所有Flatpak应用都运行在bubblewrap(bwrap)沙箱中。我刚确认过，我的环境确实如此。
> 因此若要制作恶意Flatpak，只需请求完整文件系统访问权限或D-Bus控制权即可。
这在安装时就已确定。应用程序本身无法自行更改权限。像Flathub这样的权威仓库会检查权限范围，若过于宽泛则会标记警告。用户也可通过FlatSeal等工具调整权限。这种机制与Android的权限模型基本一致。
我同意Flatpak默认设置存在安全隐患，因为它常让开发者自行决定沙盒范围。我认为这很合理，但用户有补救措施：可全局禁止所有已安装的flatpak访问特定资源，即使应用程序“请求”该资源。
我默认将所有应用程序的/home目录和网络访问权限设为禁用。通过向.local/share/flatpak/overrides/global(用户级)或/var/lib/flatpak/overrides/global(系统级)写入配置实现。希望这点能得到更多宣传。据我所知，Flatpak权限管理的事实标准工具flatseal目前尚不具备此功能。
Flatkill的论调既过时又缺乏诚意。Flathub对这类不安全权限的标注极其明确且令人反感，用户也能轻松修改设置。更令人哭笑不得的是，某些人一边声称Wayland也是安全噱头，一边又指责Flatpak因易受X11漏洞影响而存在缺陷。
正如安卓系统所示，任何安全边界都无法杜绝权限滥用问题。
> 更令人哭笑不得的是，某些人一边声称Wayland也是安全噱头，一边又指责Flatpak因易受X11漏洞影响而存在缺陷。
它们都营造了一种安全幻觉。众所周知X.org根本没有安全模型，简直糟糕透顶。Wayland设置的限制在桌面生态系统整体具备安全意识时或许合理，但现实并非如此。我听过太多诸如“Wayland让键盘记录器无从下手”之类的论调——这些说法在技术层面成立，却与现实世界毫无关联，因为桌面环境远不止Wayland这一层。
Flatpak同样具有误导性，其沙箱机制存在明显缺陷——即便抛开X11的问题不谈。
> 如同安卓系统，任何安全边界都无法阻止权限滥用。
提得很好：安卓系统要求应用向用户请求权限，而Flatpak的权限授予完全取决于开发者的设定。这根本就是设计缺陷。
https://tesk.page/2021/02/11/response-to-flatkill-org/
我始终认为密钥是为那些不应以明文形式存储在磁盘上的内容而设，而非用于隐藏其他应用程序无法访问的信息。若您的威胁模型如此设定，建议考虑虚拟机方案。
毫无辩解余地，该协议设计极其糟糕：即使不采用任何虚拟化或沙箱技术，其安全性本可大幅提升。
例如可利用内核[1]将密钥存储在内存中，仅授权创建该密钥的用户空间进程读取；其他进程请求访问密钥时，需经授权方可获取。
[1]: https://docs.kernel.org/security/keys/core.html
这正是其设计初衷。楼主纯属无端挑刺。
用户权限运行的程序可读取其拥有的数据。若这算漏洞，那整个Linux用户空间都将崩溃。你能想象我运行的应用竟能执行gpg2窃取所有密钥吗？
dbus进程由用户创建并归用户所有。唯一能访问它的只有你和root。虽然存在系统级总线，但你的密钥管理器并未使用该总线。
关键在于：https://xkcd.com/1200/
这简直像是为分时大型机设计的用户/组/所有人权限模型，如今已无法满足所有场景的需求。
实际上，这类问题对Linux桌面用户几乎不构成威胁。
因为当存在更肥美庞大的目标时，没人会在意那3%的桌面用户。
完全赞同，但GNOME恐怕无力解决此问题——据我所知，任何更完善的应用层安全模型都需大量内核支持才能实现。
操作系统明明能弹窗询问我是否要共享屏幕窗口，却不能询问是否要在应用间共享机密？我不明白这为何需要内核支持——关键在于人们是否意识到这是个问题，并愿意投入精力解决。
确实如此。任何以用户身份运行的程序都能连接D-Bus，窃取你的密钥并翻遍你的主目录。Flatpak的“解决方案”是将程序封装在无法直接访问D-Bus的沙箱中，通过过滤器代理消息。
真正需要内核支持的是为程序绑定有效身份，并在无需沙箱隔离的情况下限制其权限。其实已有现成的解决方案，dbus本身就原生支持——但许多系统用户一启用SELinux就会立刻禁用它。
幸亏如今有人工智能，大家都能把运行在自己机器上的所有软件代码送去黑盒云服务审计，从而只运行自己确信可信的软件！/s
“按预期工作，不予修复，讨论锁定”
>我决定亲自解决问题。正在编写新的总线协议。
为何不复用Binder？它已部署于数十亿设备，作为成熟操作系统的核心组件，理解它的开发者远比dbus多得多。
你可能想编写自己的服务管理器，但完全可以复用现有的强化方案。
没错！基于Binder构建新方案，利用背后拥有数量级优势的用户和开发资源…
>现有的强化方案。
为进一步强化安全性，谷歌近期为Linux内核贡献并合并了Rust语言实现的Binder版本(据悉他们计划最终移除旧版C语言实现)。
https://lwn.net/Articles/953116/
https://lore.kernel.org/rust-for-linux/20231101-rust-binder-…
除Android之外，Binder用户空间的实现方案寥寥无几。
他们的新总线到底有多少种实现方案？
考虑到任何新的Binder用户空间实现方案实际上都将与Android Binder不兼容，这究竟能带来什么实质性收益？这无异于再搞一套无人使用的通信协议，还得依赖某个冷门Linux功能才能启用。
何必另起炉灶？AOSP开源项目就在眼前，libbinder库又没有复杂依赖。
> 还依赖启用某个冷门Linux特性
但这可是经受过实战考验、企业赞助且持续开发的Linux核心特性。它在桌面Linux中看似冷门，唯一原因就是上游长期封锁。若桌面Linux广泛采用，它自然不会再冷门了，不是吗？
Binder 核心几乎完全用 Java 实现。Libbinder_ndk 只是个子集，很难让任何人满意。另一个 libbinder(openbinder)早在 2006 年左右就已弃用。我曾在某些商业产品中实际使用过这个版本。
> 然而作为企业赞助且持续开发的特性，Binder已是Linux系统中极其普及且久经考验的组件。
相较于_unix套接字_——几乎所有本地进程间通信机制都采用的另一种传输方式，也是D-Bus的底层协议——两者根本不在同一水平线上。即便Android系统使用unix套接字的频率也远高于Binder。
> Binder核心几乎完全用Java实现
Binder本身没有任何Java代码。Java层仅是通过JNI绑定到原生实现的接口。
权限管理器等组件虽用Java编写，但不属于Binder核心。它们只是发布在Binder上的服务，且这类服务在当前桌面Linux环境下本就无法移植。
> 相较于_unix套接字_——几乎所有本地IPC机制都采用的另一种传输方式，无论是D-Bus、TFA提案还是任何其他合理的桌面IPC方案都基于此——两者根本不在同一层面。
unix套接字并非等效方案，正因如此才需要在顶层附加协议才能形成D-Bus等系统…
编辑：
> 另一款 libbinder(openbinder)自2006年左右已停止维护。
我所指的 libbinder 是 AOSP 中的版本，因此才说“AOSP 就在眼前”：
https://cs.android.com/android/platform/superproject/main/+/…
这个框架自2006年左右起就绝对没有消亡。
“Binder完全不使用Java”的说法过于绝对：https://android.googlesource.com/platform/frameworks/base/+/…
这个libbinder库依然高度依赖Java。它支持外部调用，甚至让我想起openbinder(例如
sp<>https://cs.android.com/android/platform/superproject/main/+/…)，但整体格局并未实质改变。这东西从老远就能闻到Java的味道，还掺杂着大量Android特有的东西，所以要真正应用于大多数桌面程序，恐怕还是得重新发明很多轮子。即便使用C++也可能让很多人皱眉(我除外)。
这是libbinder中某个类的Java版本。同时提供Java和原生版本的类，是面向双平台设计的常见模式。
https://cs.android.com/android/platform/superproject/main/+/…
不，并非如此。正如前文所述，这是个带有原生方法的Java类，这些方法调用C++版本。但它本质上仍是Java类。
dbus-java的存在，难道能让dbus神奇地变成主要用Java实现的吗？
当然不会，这太荒谬了。Parcel和Binder的情况也相同。Java绑定存在的事实，并不能改变Binder本身不含任何Java代码的本质。它经常被完全不含Java的进程所使用——这并非假设，而是基本事实。正因如此，Binder才被用于HAL等底层系统。
Binder的C++起源确实令人困扰，但与原始Binder[1]不同，它易于绕行——尤其考虑到除少数标准位外，消息的精确格式完全由实现方决定
[1] BeOS，其文档至今仍与Android版本完全吻合 😀
并非完全如此，你需要就线协议的某些约束达成共识，因为内核最终会对通过该协议发送的对象进行引用计数。
直接采用Android的实现方案即可
这难道不是与Android的权限和应用模型紧密绑定吗？该模型与通用Linux存在根本差异。
希望有发行版能在桌面系统实现Android的权限机制。Unix权限体系诞生于多人共用单一操作系统(如今这类场景由虚拟机解决)的时代，而非为保护同一用户运行的不同应用而设计。https://xkcd.com/1200/
鲜为人知的是，原始的Binder协议OpenBinder甚至并非为Linux或Android开发，而是专为BeOS系统创建。
OpenBinder是Be公司濒临倒闭前夕(被Palm收购前)罕见开源的代码之一。
参与OpenBinder开发的核心Be工程师——Dianne Hackborn、Jean-Baptiste Queru等人随后从Palm跳槽至Danger公司，该团队正致力于Android开发，后被谷歌收购。
正如人们常说的，剩下的就是历史了。
哪个操作系统？搜索BSD绑定器没找到多少结果。后来我猜你可能是在开玩笑说“严肃”，于是试着搜索Windows绑定器、iOS绑定器，也没看到多少内容…
Binder是Android系统中应用程序与各类操作系统服务交互的主要方式。
https://source.android.com/docs/core/architecture/ipc/binder…
https://www.kernel.org/doc/html/latest/admin-guide/binderfs….
包括驱动程序——自Project Treble以来，从Android 8起所有新驱动程序都必须采用用户空间实现，通过Android IPC(即Binder)与内核通信。
传统Linux驱动程序在Android中被视为遗留组件。
驱动程序的用户空间部分固然如此。但若仅存在于用户空间，它们将无法实际调用硬件资源。必须成为Linux内核模块的一部分，才能与硬件进行交互。
https://source.android.com/docs/core/architecture/ipc/binder…
Binder比D-Bus更优越吗？具体体现在哪些方面？
1. 开发体验更佳。Binder的工具链会严格检查事务读写是否正确，错误操作将导致编译时报错。而使用D-Bus时，即使调用方式错误仍能通过编译。
2. 延迟更低。向其他进程发送Binder事务时，Linux会立即调度目标进程的Binder线程(除非是不会阻塞执行的单向事务)。当目标进程响应后，发起进程将立即重新调度。而DBus不影响Linux进程调度机制，发送消息时系统可能调度其他进程运行，导致消息传输过程中出现额外阻塞。
3. 消息经由总线传输还会产生额外复制开销。这不仅涉及低成本的内存复制，由于通过UNIX套接字传输，还需额外调用系统函数进行套接字读写操作。而Binder能直接在进程间复制数据包内存。
Binder即将登陆Linux桌面…与Android同步推出 🙂
是否有桌面环境计划用Binder替代D-bus？
从本文风格判断，我原以为https://github.com/hyprwm/hyprwire (https://github.com/hyprwm/hyprwire)和https://github.com/hyprwm/hyprtavern会提供文档、规范及大量测试，但实际内容寥寥(仅有烟雾测试)。
这些本可成为绝佳的起点！不过或许日后会补上。
据我所知，目前唯一作者正在忙于大学毕业考试。
公平地说，他们在文章中多次声明这些内容“尚未完成”。等他们忙完再看吧
OpenWrt开发者多年前就顿悟了：
https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus#what_s_the_difference_…
(此处无意推荐；尤其ubus的安全模型相当薄弱，尽管OpenWrt对此有其理由)
> 见过 kwallet 或 gnome-keyring 吗？对，就是这些玩意儿。它们号称是用于存储签名密钥、密码等信息的“秘密仓库”。这些仓库可以设置密码保护，这意味着它们很安全…对吧？[…] 实际上，只要仓库处于解锁状态，任何应用都能读取其中的所有机密信息。
今天学到新知识。看来默认的图形界面是
seahorse，现在来看看我这个相对干净的系统里有什么… 主要是Chromium相关的内容，里面有个解锁应用专属密钥的密钥(比如Discord的)，还有我JetBrains账户的访问令牌。虽然没有明文密码，但现在我开始担心恶意应用追踪本地Chromium数据时可能挖掘出什么。
你认为这些密钥还能存储在其他地方吗？打算如何验证访问权限？
若用户从未输入过密码，这些密钥本就存在于内存中，任何应用都能访问。若系统未提示或通知访问行为，那么具体由何种软件机制管控已无关紧要。
在Android、iOS和macOS等平台，密钥可通过加密存储轻松保护，除非利用内核漏洞否则无法获取密钥。Windows虽有类似功能但需手动启用，兼容性问题使其可靠性稍逊。
iOS和macOS结合了沙盒技术与安全元件。Android采用可信执行环境(TEE)或类似安全元件的硬件。Windows则使用虚拟机监控程序+(f)TPM。
Linux完全能实现这些功能，本质上是通过API将小型早期启动KVM虚拟机+TPM+安全启动整合起来。不过在许多消费级设备上，配置自定义安全启动密钥以实现相对无缝运行相当麻烦。
上述方案仅保护设备静态存储的密钥。若应用程序直接向安全模块索取密钥后直接发送给第三方，则毫无防护可言。
在我这台受安全启动保护、全盘加密的笔记本电脑中，密钥环内的密钥在启动前与Dbus解锁密钥环前，安全性完全相同。
Android应用绝不可能通过密钥管理器窃取彼此的机密——即便在应用运行期间也无法实现。iOS应用同样如此。或许能通过浏览器漏洞诱使它们泄露会话令牌，但这完全取决于应用开发者的设计。
Windows的凭据守护程序(Credential Guard，https://learn.microsoft.com/en-us/windows/security/identity-…)正是针对“系统运行时导出所有机密”的攻击方式设计的防护机制。
即便是Mimikatz工具，也需要利用设计漏洞且必须具备管理员权限才能生效。
若能突破内核及其所有防止机密外泄的防护机制，或许能解密其他应用程序的数据，但这与Linux环境截然不同——在Linux中，任何以标准用户身份运行的应用程序只需简单请求就能倾倒整个凭证数据库。
> 若应用程序直接向安全模块索取凭证后便将它们全数邮件发送给他人，这种保护形同虚设。
在Windows系统中，应用程序可指定额外熵值/盐值，缺少这些参数则无法解密密钥[1]。因此相较于直接索取，这种方式的泄露难度略高。
[1]: https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf…
这依然是在保护静态密钥。
人们究竟没搞懂什么？共享密钥库的意义在于让应用程序共享密钥。我的Git令牌就共享在Git、IDE、各类脚本之间。
这场讨论恰恰凸显了核心问题：人们甚至不清楚自己究竟在解决什么问题或满足什么用例。
密钥链访问可通过ACL限制，在iOS上还能通过代码签名强制执行，而在macOS上更严格——这里的“密钥链”仍可能是旧式的文件型存储。
有些机密信息，除非禁用Mac的SIP，否则我无法从系统密钥链导出。
你认为任何安卓或iOS应用都能窃取所有存储的密钥？
> 若用户未在任何环节输入密码，这些密钥本就存在内存中且可被任意程序访问。
用户登录时必然输入过密码。况且Linux系统多年来就设有限制ptrace的配置项。
当重要银行应用将密钥存储到我的“钥匙串”时，我绝不会料到这个“密钥”竟能被其他运行程序轻易获取。
试想若浏览器也如此运作——每个保存过密码的网站都能查看所有其他保存的密码…
为什么你的银行应用会将密码存入钥匙串？这就像把保险箱密码写在纸上，然后挂在实体钥匙串上。
问题不在于钥匙串存放了什么，(已报告的)问题在于任何程序都能随意完整查阅其内容。门锁本不该能枚举并复制所有非专属钥匙。
> 为何你的银行应用会将密钥存入钥匙串？
所谓“钥匙串”的存在意义，不正是为了保管那些保密且专属的物品吗？
此处的症结在于用途之间的泄露。即便银行应用仅为方便存储我的登录名，我也不允许Linux BonziBuddy能随意抓取该信息。[0]
> 这就像把保险箱密码写在纸上，再挂在实体钥匙串上。
既然如此，为何还要把普通钥匙挂在漏洞百出的钥匙圈上？(A)看到密码锁的数字组合与(B)看到易于复制的钥匙形状，本质并无区别。[1]
[0] https://en.wikipedia.org/wiki/BonziBuddy
[1] https://en.wikipedia.org/wiki/Bitting_(key)
Unix对此已有成熟的安全模型：用户与组。可创建名为
banking的新用户，专用于所有银行操作。尤其在X11模型下，只需输入startx即可启动，无需为维持桌面环境运行而启动大量软件。你真的尝试过这种方案吗？为所有程序分配独立用户？
事实上我本周正尝试类似做法，即让Spotify(以snap形式分发)以独立用户身份在可见窗口运行。或许可行，但绝非轻而易举或开箱即用。
这正是Android的做法。桌面版Linux理应实现得更便捷。
dbus的另一问题在于，所有将网站与gnome/kde集成的浏览器扩展都通过dbus通信。这些dbus接口存在多个拒绝服务漏洞，部分漏洞仅需访问任意网站即可触发。仅因dbus接口被洪水攻击就导致桌面环境崩溃是不可接受的，更何况这种攻击竟能通过访问网站实现。
因此若你是安全研究者，dbus绝对是值得深入研究的切入点——尤其当目标是改进开源软件时 🙂
哪些浏览器扩展？我为何需要网站与gnome或kde集成？这到底是什么意思？
这家伙不是默认安装在大多数Gnome发行版里吗？https://chromewebstore.google.com/detail/gnome-shell-integra…
我猜楼主指的是USB和蓝牙浏览器协议(至今仍觉得这种设计荒谬至极，但确实是当前配置某些键盘的唯一途径)。
这些不是扩展程序。更不可能用来与dbus通信。
独立虚拟机下不存在此问题 😀
现在你面临两个问题了。
s,VM,WM，抱歉。不，并非两个问题；我始终能通过dbus-launch启动任何需要dbus的工具，同时保持窗口管理器独立运行。
D-Bus是Linux桌面最接近XPC、COM和Android IPC的存在。
或许该更善待它，别动不动就重启。
问题根源在于Linux桌面的碎片化，阻碍了应用开发的完整栈式方案。
GNOME适用的方案对KDE毫无用处，KDE适用的方案对XFCE毫无用处，而Sway等又完全忽略XFCE。
> GNOME适用的方案对KDE毫无用处，KDE适用的方案对XFCE毫无用处，而Sway等方案又完全忽略了XFCE。
KDE曾有自己的IPC方案DCOP，但已被D-Bus取代。
没错，自1995年起便使用各种形式的Linux。
D-Bus已有二十余年历史，确实该重启了。这位抱怨者并非全无道理，但多数批评确有其理。然而升级桌面基础设施不仅关乎技术卓越性，更涉及影响力(话语权)与“社会”优势。缺乏主流厂商支持的新IPC机制注定无望。
我认为vaxry绝对是重要玩家——随着omarchy.org和r/unixporn的崛起，hyprland已足够普及，使他具备足够势能来发布TWM Linux桌面新时代的标准规范。
在Linux桌面社区拥有核心影响力才是此类项目成功的关键驱动力。而他目前尚未达到这个地位。
总体而言，窗口管理器生态系统主要分为平铺式窗口管理器与其他类型两大阵营，其中前者在桌面开发者群体中的覆盖率微乎其微。
即便在原本就狭小的Linux桌面社区中，omarchy及极端定制化(“unixporn”)的用户群体也微乎其微。所谓omarchy甚至平铺式窗口管理器“统治”桌面世界的论调，不过是YouTube网红和技术宅们炒作的夸张幻觉。若你看过他们在视频中操作时的窘态，就会明白这不过是场表演——omarchy的发布视频堪称最佳例证。
说真的，谁在乎呢？
这无疑会被许多Hyprland用户采用，而我真心觉得Vaxry根本不在乎其他事。他只是个来自波兰的大学生，如今获得的捐赠已足够让他永远不必为他人工作(除非他愿意)，完全可以继续发展自己的生态系统。
实际上KDE有KParts，类似于COM。D-Bus出现前KDE曾使用DCOP。
天啊我超爱KParts，但那不就是“万物皆可嵌入”的理念吗？
> KPart技术用于KDE中复用GUI组件… 开发者在应用中使用KParts后，无需耗费大量时间实现文本编辑器或命令行功能，直接调用katepart或konsolepart即可。
https://techbase.kde.org/Development/Tutorials/Using_KParts
确实如此，但自“KDE 5”以来这种设计已日渐式微。除Konqueror这个典型案例外，reKonq曾是另一杰出范例——它整合Akregator处理RSS订阅、Okular处理PDF文档、Kget管理下载任务(所有操作均在reKonq窗口内完成)。
如今连Falkon浏览器也不再采用这种设计。
作为用户，我随手就能列举出几个例子：多款应用(如Dolphin或Yakuake)使用konsolepart；KWrite采用katepart；Ark在文件预览中整合了多种组件。
确实如此，但仍仅限于KDE应用程序使用。
碎片化是不同使用场景并存的必然结果。
鱼与熊掌不可兼得。
正因如此，WSL 2.0终将迎来桌面Linux的时代，而Android、WebOS与ChromeOS的共通点在于Linux内核，而非用户空间。
> ChromeOS的共通点在于Linux内核，而非用户空间。
ChromeOS通过Crostini虚拟机实现了Linux用户空间的深度集成。
部分原因在于实际运行效果因Chromebook型号而异。
若用户仅需命令行和文本界面(TUI)体验，这固然理想。
但启动3D加速的图形界面应用？那就另当别论了。
> 若用户仅需命令行和文本界面，这确实很理想。
常规图形应用在ChromeOS上运行良好。通过启用虚拟机GPU的配置项，3D加速图形应用也基本能运行。不过若指游戏性能，系统并未针对此进行优化。
我怀疑D-Bus的设计是否与我常观察到的现象有关：面对特定问题时，最优解往往无法脱颖而出，取而代之的是看似由绝对随机性选定的方案。例如，GitHub上可能存在多少个真正比React优秀100%的框架，却因作者未能推广而意外地默默无闻？D-Bus是否也存在类似情况？
恕我直言，这种现象多半源于评估方案者未能完全理解问题本质。需求往往与人们的认知存在偏差，导致胜出方案看似随机——实则源于对真实需求的误判。
D-Bus因与GNOME的关联而崭露头角，而GNOME之所以持续活跃，主要得益于其与红帽的紧密合作。
不，其重要性源于Ubuntu将所有桌面技术栈都基于GNOME构建(除中途放弃的Unity 8外)。
过去二十年间，红帽始终是GNOME最大的单一支持者——无论资金投入还是人才输送。其年度报告虽未明确说明，但这种状况是否已改变？
大多数时候，根本不存在什么“最功勋卓著”之说，无非是某些方案在“权衡空间”中的位置偏离了发言者的偏好罢了。我向来看不起那些对他人成果(比如原帖文章)冷嘲热讽、傲慢否定的人——仿佛世上存在某种“显而易见”的正确解法，而那些推动广受认可方案的人要么愚蠢至极，要么别有用心。他们不可能有其他优先事项，也不可能在缺乏中央控制的复杂生态系统中竭尽全力实现可接受的运行效果——不！他们只是比你愚蠢(或纯粹恶意)。
更糟反而更好，但这很元，因为最糟的选择方式反而胜出
部分问题在于这些项目全由志愿者开发。当仅有一人、三人或更少人愿意投入数十万小时个人时间时，决策权便掌握在他们手中。几乎没有任何“高层管理”机制能纠正错误决策。
更糟的是这里存在逆向选择。谁会为Linux桌面某个冷门角落投入数千小时？必然是思维方式相当特殊的人。
https://en.wikipedia.org/wiki/Worse_is_better
D-Bus背后有红帽公司的鼎力支持。
说到底，这纯粹是政治博弈。
世间充斥着“足够好”的解决方案。只要满足80%的功能需求，对多数使用场景而言就已足够。
> 最优秀的方案却永远无法脱颖而出
知道为什么吗？因为它在当时是满足所有需求的最佳方案。你之所以抱怨，只是因为最初的问题已解决，人们得以转向其他领域。
它能满足我们的需求吗？能？那就行。既然问题已解决，我们就能继续前进。
唯才是用只适用于那些满腹空想却无意愿或无能力将构想转化为现实可行方案的人。
> D-Bus是否也有类似机制？
所以你在此评论的实质无非是：“D-Bus很糟糕，因为它并非最佳方案。不知是否有更优选择？”
据我所知，它最初作为自由桌面项目开发，旨在创建通用标准桌面总线——毕竟当年KDE和GNOME各自拥有独立总线。
这里绝对存在操纵天平的精英集团。
D-Bus的普及就是其中一环？快说出来！
深层政府强迫所有人使用GNOME，真是令人摇头叹息
为何需要通用总线协议？
通过Unix域套接字使用HTTP，甚至在Unix域套接字上实现带大小头+JSON负载的简单协议，在多数语言中都轻而易举。Unix域套接字遵循标准Linux权限机制，可通过curl访问、ssh转发、容器挂载等方式灵活操作。每个服务对应单一套接字即可。
D-Bus却是个过度复杂的混乱体系。它用服务、接口、路径和方法层层分类消息，但消息仍存在部分标识缺失，且每个消息流都依赖独立连接。虽然存在返回消息ID，但部分服务仍采用轮询机制。即便部署了D-Bus，仍需掌握应用专属协议细节才能解析消息。应用协议会将底层细节泄露至消息中(例如视频访问请求会将随机生成的dbus标识符复制到有效负载中)，这使得通用处理D-Bus消息(如代理转发)根本不可行。
> GNOME项目方对该漏洞报告持异议，因其安全模型明确规定：未受信任的应用程序不得与秘密服务通信。
> 通过Flatpak沙箱化的应用仅能过滤访问会话总线。
虽然我理解他们为何认为这是糟糕的回应，但这实在让我想起这个案例：https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31…。他们不仅省略了引文末句，还截了图导致内容无法复制。谁他妈干这种事？
Wayland啊，你若无root权限，休想截屏。
D-Bus，YOLO！
我也不是Wayland的拥趸，更希望不同用户能同时运行程序访问同一应用服务器。这在Xorg上完全没问题。
在Wayland上同样可行。这不过是个可设置权限的Unix套接字，比X11的魔法cookie机制更简单。
当你想要替换一个失效的工具/系统，且需要获得广泛社区支持时，查理·马什处理ruff和uv的方式堪称黄金标准。
他并未大张旗鼓地冲进来高喊“pip是耻辱”和“这他妈是个笑话”。而是编写了一个更优秀的工具，并鼓励他人尝试使用。短短一年左右，这场变革便如滚雪球般势不可挡。
当前该项目仅包含若干C++文件，既无文档也无测试，更缺乏取代d-bus的路线图——一无所有。正如其他评论者所言，在2025年启动新系统服务时高喊安全口号，却采用不安全的语言开发，实在难以令人信服。
Lennart Poettering、Theo de Raadt和Linus Torvalds或许能靠这种言论蒙混过关，但若真心想凝聚广泛社区支持(否则整个项目根本无法启动)，请向Charlie学习。
对了，若你觉得D-Bus糟糕，那你该庆幸没用过它取代的那个东西——CORBA。
说得没错。D-Bus其实也没那么糟糕，我们只需解决这个SecretManager问题…
> 该项目目前堆积着大量C++文件，既无文档也无测试
我认为协议本身比具体实现更重要。正如作者所言，当前D-Bus标准充其量只能算次等。
若有协议规范——至少是草案之类比“酒馆”更具象的东西——我倒能接受。
眼前这堆无文档的C++代码实在令人无语。
我认为你前文评论的核心观点在于：真正能推动事物发展的，是那些切实可用的解决方案，其效力远胜于空谈理论或制定协议。加密算法/协议领域同样如此：即便设计出最完美的算法，若缺乏优质的参考实现供人们使用，它终将无人问津。
同样地，我希望那些想扩展现有技术并加以改进的开源开发者能借鉴微软的“拥抱、扩展、消灭”策略。比如："这是我的新D-Bus实现，它有几个额外的花哨功能，正好满足我的项目需求，而且运行更快。哦对了，我还加强了安全性，你现在不必使用它，但某些服务将强制要求。…安全功能现已强制启用。…协议正式更名为Wire，若需D-Bus可运行此遗留转换层。…该转换层不再默认安装，但会为有需求者保留维护。…三十年来无人再需要D-Bus，我们终止转换层维护。"
这与楼主的做法如出一辙，只是措辞没那么直接挑衅。无论如何祝他好运。
此刻我真想让CORBA回归。
没错！网络优先永远是真理。我们需要某种“网络对象模型环境”，让服务能存在于网络任意节点。
只差个响亮的名字。
那就叫“原型船长RPC”吧
> D-Bus是GNOME团队约20年前推出的。相比X窗口系统40年的历史，这个仅有20年历史的软件竟同样糟糕得令人惊讶。
我可不这么认为。Emacs才是真正的牛逼。
我认为他们并非暗示老软件永远糟糕。
不过很多实现确实不怎么样。
你们能不能别天天重新发明轮子？我跟所有人一样讨厌D-Bus，尽管它至少催生了Utopia项目之类的垃圾。但即便觉得它烂透了，我仍坚持使用——原因很简单：创造的替代方案越多，给其他用户带来的困扰就远超任何实际收益。从LG电视到汽车系统，D-Bus早已无处不在——至少它他妈能用。
缺少规范？自己写一个。
你真想让secretd之类的服务只对存储密钥者响应？让客户端存储cookie之类凭证，验证所有权后再响应。但必须问：你们的威胁模型到底是什么鬼？攻击者大可直接通过ptrace监控Firefox读取所有密钥，或直接读取$XDG_CONFIG_DIR目录下的文件。你不过是在推卸最终责任，这根本是安全表演。况且我_希望_其他程序能读取密钥(如密钥管理器、.netrc风格的共享密钥等)。
你讨厌a{sv}吗？若提议用JSON替代，简直可笑至极。
等等等等。
> 让客户端存储cookie之类凭证，仅在验证所有权时才响应
Unix域套接字认证更安全，且无需在客户端存储cookie。
> 你这到底是什么威胁模型？攻击者反正会直接用ptrace监控火狐并读取所有密钥。
正因如此，人们才需要(且确实存在如flatpak这类)阻断ptrace或全局文件系统访问的应用运行环境。这正是门户机制存在的意义，也说明不该存在“通过dbus获取所有密钥”的后门。
> 我_希望_其他程序能读取密钥(比如密钥管理器、.netrc风格的共享密钥等)
那别用啊？安全默认设置对大多数用户才重要。
> 你讨厌a{sv}吗？要是提议用JSON替代，你可真让我笑掉大牙。
关键参数详见：https://wayland.app/protocols/xdg-shell
诸如此类。这已不是90年代了。
> Unix域套接字认证更安全，且无需在客户端存储cookie。
但在此毫无意义，因为所有进程都运行在相同uid下。你需要验证的是：当前浏览器是否与存储密钥的浏览器一致——而非验证相同uid(毫无意义)、相同pid或其他Unix域套接字认证能识别的概念。
> 正因如此，你才能(且人们确实如此操作，例如flatpak)在阻断ptrace或全局文件系统访问的环境中运行应用。这正是门户机制存在的意义，也说明不应存在“通过dbus获取所有密钥”的后门。
这种情况下它们根本不连接同一D-Bus总线，问题自然不复存在。参考 flatpak 沙箱机制的实现方式。
> 那干脆别用？对多数用户而言安全默认设置至关重要。
直到他们发现无法查看密钥环内容，或是遭遇其他桌面用户根本不在意的愚蠢限制。
事实上，若无需共享密钥服务且应用已容器化…何必依赖密钥 IPC？让每个程序将其密钥存储在所谓的私有存储中即可…
> 相关参数详见：https://wayland.app/protocols/xdg-shell
让无数不可扩展的协议相互竞争岂不更好？时至今日，仅暴露桌面环境DbusMenu服务地址就存在至少两种协议——gnome-shell一套，kwin一套。X原子机制的丑陋性可见一斑。而这与IPC机制本身的设计毫无关联…
> 事实上，若无需共享密钥服务，且应用程序均采用容器化部署…何必需要密钥IPC？让每个程序将其密钥存储在专属的私有存储空间即可…
若我将密钥存储在号称专为密钥设计的KWallet中，无论是否愿意共享，我绝对不希望桌面上的所有应用都能访问这些密钥。
你居然认为这种设计合理，实在令人难以置信。
KWallet从未提供过任何安全保证，所以你惊讶什么？它的设计初衷就是集中化共享(即避免在每个程序里反复输入密码)。
这根本就是行业惯例，不仅限于Linux——所有桌面操作系统都如此。除了macOS，而且是最近才改变的。
Kwallet只负责静态加密，攻击者窃取电脑后无法读取你的密钥。它绝非针对同用户权限下运行的应用程序的防护机制。
这根本不符合Linux桌面的运作逻辑。它是个桌面操作系统，不是iOS。所有以你用户身份运行的应用都拥有你的用户权限。
这是过时的安全模型吗？没错，沙箱技术和新内核特性已取代它。但若你不采用这些方案，就别指望获得更高级别的保护。
直接用Flatpak运行你的软件，问题迎刃而解。更稳妥的做法是：别安装恶意软件，只从可信仓库下载可靠开源软件。
自Docker问世以来，我们已掌握相当成熟的隔离技术(部分技术被Flatpak等沙箱继承)——只需将组件置于不同命名空间，通过认证API让进程“挂载”所需资源即可。
越是遵循内核安全模型，应用就越安全高效，其他开发者就越不会因偏好自研方案而拒绝采用它。
> 这里毫无意义，因为所有进程都在相同uid下运行。你需要验证的是：当前浏览器是否与存储该密钥的浏览器相同，而非验证相同的uid(毫无意义)、相同的pid，或任何Unix域套接字认证所理解的概念。
我不同意。通过Unix域套接字完全可以确定通信对象的进程PID，并利用pidfd验证来源。这完全可用于策略实施。
事实上，如果你不需要共享密钥服务，且应用程序都容器化了……那你根本不需要密钥IPC对吧？直接让每个程序把密钥存进它所谓的私有存储空间就行了……
那么应用容器服务究竟如何在磁盘上安全存储加密内容？这恰恰是现代桌面环境中密钥服务的核心价值。它通常通过PAM传递用户密码获取密钥，从而实现无需独立密钥管理密码的磁盘加密。(当然，理论上可借助TPM等技术规避密码，但核心逻辑并无二致——不应让每个应用各自负责安全存储方案，这只会导致数据丢失和混乱。)
> 更理想的方案是让无数不可扩展的协议相互竞争。时至今日，仅暴露桌面环境DbusMenu服务地址就存在至少两种协议：gnome-shell专属方案与kwin专属方案。这恰恰印证了X原子机制的臃肿弊端。而这与IPC机制本身的设计并无实质关联…
问题根源在于协议存在多重独立实现。多数DBus服务根本无需面对这种困境。(而那些需要应对的，往往遭遇类似问题——不同XDG桌面门户实现间存在大量怪异的兼容性问题。)
我确信提及xdg-shell是因为新总线借鉴了Wayland协议。尽管网上对Wayland的抱怨不绝于耳，但Wayland协议的使用体验比dbus优越千倍。你甚至能为其生成优质代码，无需像dbus那样存在五种相互竞争的XML扩展方案来添加结构体成员注释这类基础功能(更别提Qt自带的DBus代码生成器根本无法处理真实的DBus服务定义。试试用systemd的定义喂它试试，他妈的根本不工作。代码连编译都通不过)。
> 确定通信对象进程的PID，并通过pidfd验证其来源。
pidfd_open()手册页并未详述pidfd的具体操作方式。您设想的验证机制是怎样的？
我希望能实现一个具备合理防窥探能力的秘密存储服务，其安全模型能兼容普通程序(而非强制要求使用Flatpak等特殊环境)。
我提出pidfd方案的初衷只是为规避竞争条件，不过仔细想想或许并非必要。具体如何验证可执行文件，你可自行选择方案。我的构想是通过检查/proc/…/exe目录确认文件属于root所有(且位于root拥有的目录结构中)，再以其绝对路径作为密钥。这似乎是个不错的起点，能在任何操作系统上实现基础验证。
若需要，添加代码签名也是可行的方案，不过会带来额外挑战。如我在其他地方提到的，任何想在此处建立真正安全边界的设计，都必须应对通过LD_PRELOAD等潜在绕过手段。不过我认为必须循序渐进。
> 通过UNIX域套接字完全可以确定通信进程的PID，并利用pidfd验证其来源。
验证什么？你只是将责任转移到你给出的任何答案上。如果你说“验证执行文件名是firefox-bin”，那么下一个进来的人就会说“我讨厌你的新奇IPC方案，只要把执行文件重命名为firefox-bin就能泄露所有机密”。(这只是个例子)。
> 那么应用容器服务究竟如何将加密内容安全存储在磁盘上？这恰恰是现代桌面环境中密钥服务的核心价值所在。
越想越觉得这毫无意义。既然已有系统确保应用程序无法读取彼此数据，密钥服务还有何存在价值？其安全优势何在？
若想通过TPM、指纹或其他方式加密，这属于独立于存储层的加密操作(例如用PCR加密密码，但应用程序仍可自由选择存储加密密码的方式)。
桌面密钥环中的密码加密机制，正是为“所有应用程序都能轻易读取彼此数据文件”的场景设计的(再次强调，这是桌面环境的特性)。这种情况下，采用加密确保数据不被其他应用程序轻易访问(否则将出现https://developer.pidgin.im/wiki/PlainTextPasswords所述问题)才具有实际意义。
如果应用程序已在沙盒环境中运行，那么密钥环似乎只是徒增复杂性？只需让每个应用程序将数据存储在各自的沙盒中即可。这里存在什么威胁途径？难道是某个能逃脱沙盒的超级用户能读取沙盒内容并提取密码？
> 其实完全可以实现合理的代码生成方案，无需像现在这样存在五种相互竞争的XML扩展方式来添加结构体成员注释这类基础功能(结果导致Qt自带的DBus代码生成器根本无法处理真实的DBus服务定义。试着给它扔个systemd的定义试试，他妈的根本不工作。代码连编译都通不过。)
没错，这又是标准化缺失导致的问题。但我的核心观点是——应该制定规范(编写标准文档)，而不是通过创建更多相互竞争的标准来加剧问题，这些新标准显然无法解决标准化缺失的根本症结。
> 验证什么？你只是把责任推给了你给出的任何答案。如果你说“验证执行名是firefox-bin”，那么下一个进来的人就会说“我讨厌你那破IPC机制，只要把执行名改成firefox-bin就能泄露所有机密”。(这只是个例子)。
老实说，人们竟在这点上绊倒，我有点意外。显然，验证什么取决于你，但你完全可以验证。何必只验证基础名称？为何不验证绝对路径？若能确保文件属于root用户且位于root拥有的路径中，那就更完美了。你可以为Flatpak或特定挂载点设置特殊规则，甚至可以疯狂地给二进制文件添加签名。策略显然会因系统而异，但若处理的是启用dm-verity安全启动的系统(或类似机制)，这种机制应该相当严密。即使存在安全特性不同的系统，也并非世界末日。
你完全可以发挥创意。
(但需注意，此机制可通过LD_PRELOAD等手段轻易绕过，若要成为真正的安全边界仍需深入设计。不过现有方案确实存在诸多改进空间。)
> 愈是深思，愈觉荒谬。若系统已确保应用程序无法读取彼此数据，秘密服务有何意义？安全优势何在？
显而易见的初始优势与DPAPI长期存在的特性相同——即数据在磁盘上处于加密状态。这固然有益，因为它最大限度减少了接触原始密钥的组件数量，确保其他特权进程也无法直接读取用户密钥。深度防御理论表明，多重安全机制的重叠是优势而非缺陷——若每项机制单独使用时都足以抵御攻击，则更显价值。
值得考虑的另一场景是当用户主目录通过网络文件系统存储在远程位置时，这常见于企业级应用场景。
> 若采用TPM、指纹或其他方式加密，这属于独立于存储层的加密操作(例如用PCR加密密码，但应用程序可自由选择存储加密后的密码方式)。
让每个应用自行处理用户数据加密实属不智。若需自主管理存储，应用可将密钥存储于密钥环而非数据本身(确信某些场景已采用此方案)。
> 桌面密钥环中的密码加密机制适用于应用间可轻松读取彼此数据文件的场景(再次强调，此为桌面环境特征)。在此情境下，采用加密可防止其他应用程序轻易访问此类数据(否则将触发https://developer.pidgin.im/wiki/PlainTextPasswords所述问题)。
该页面旨在解释为何不采用加密方案，但部分原因在于根本不存在可选方案。若真有可选方案，情况自然不同。
> 若应用程序已处于沙盒运行环境，密钥管理器在我看来岂非徒增复杂性？只需让每个应用程序将数据存储于其沙盒中即可。此处的威胁途径究竟是什么？难道是某个能逃逸沙盒的超级用户能读取沙盒内容并提取密码？
威胁载体可以是任何形式，这种机制有诸多潜在用途。现实情况是，Linux桌面系统并未将所有程序置于沙箱环境中运行，且我们也并未朝着这个方向发展。这部分原因在于：在Linux系统中，多数程序本身已通过发行版的预先审核被视为“可信”(即便它们受限于SELinux或AppArmor等强制访问控制机制，如SuSE系统所采用的方案)，因此额外添加沙箱机制显得多余且可能带来不便(例如Bottles环境中的文件访问问题便是典型例证)。但即便在所有桌面应用都运行于气泡膜保护层的场景下，多层互补的防御机制依然值得拥有。即使有人或程序成功访问了你解密后的主目录数据，最敏感的部分仍能获得保护。
> 没错，这确实是缺乏标准化导致的又一问题。但我的核心观点是——应当制定统一规范(编写技术规范)，而非通过创建更多相互竞争的标准来加剧问题，这些新标准显然无法解决标准化缺失的根本症结。
人们不愿着手解决(依我之见)是因为DBus开发令人沮丧。DBus之所以混乱并非源于一两个问题，而是从根基起就布满无数缺陷。
关键问题就在于此：若你希望对这些问题的解决方式产生影响，我们非常欢迎你亲自尝试改善DBus现状。当然你并非必须如此，但若你对参与解决此问题毫无兴趣，我实在看不出为何他人要对你提出的修复方案意见如此重视。
> 看到大家在这点上绊倒，我真心有点意外。验证什么内容固然由你决定，但完全可以更进一步。何必只验证基础名称？为何不验证绝对路径？若能确保文件属于root用户且位于root拥有的路径中，更是锦上添花。
因为你根本没搞懂：这可不是安卓系统。这里没有固定的UID，没有固定的绝对路径，二进制文件也不总是root所有。更没有中央签名机构(谢天谢地！)。你真的没明白：在桌面Linux环境中，通过PID验证的任何内容都毫无意义。
> 你可以为Flatpak或特定挂载点开特例，或者干脆给二进制文件加签名。
或者，既然假设使用Flatpak，干脆禁止访问会话总线，只允许访问经过过滤的总线——该总线仅允许与Flatpak提供的服务通信。这正是Flatpak的做法，能彻底规避总线客户端认证的噩梦级难题。所有从原始Flatpak会话派生的进程树仅能访问该总线。
> 即使其他特权进程也无法直接读取用户密钥。深度防御理论表明：多重安全机制的重叠是特性而非缺陷。若两者各自独立时均能有效抵御攻击，则更显价值。
我实在看不懂这种设计的意义。当然希望特权进程能读取我的密码——这可是_我的_桌面系统。
我不明白为何要让“沙盒应用”存储私密数据，却另设所谓“更安全”的存储空间(无论你如何定义安全)。直接将数据存入“更安全”的存储空间不就好了？
你描述的并非额外安全层，而是毫无意义的复杂化。正如我所言，越思考越觉得这种不共享密钥的“秘密服务”毫无存在价值。
这导致荒谬的设计结论——必须构建只向原始插入进程返回值的键值数据库服务器，就像TFA所做的那样。为什么？究竟为什么？？？直接创建多个完全独立的私有实例不就行了！你明明已有现成的存储方案：应用的私有存储空间。这种场景根本不需要进程间通信(IPC)！
> 让每个应用自行处理用户数据加密实属不智。
为何？你未说明反对理由。当前所有应用都在这么做，且从未需要过IPC(例如OpenSSL是库而非服务)。
> 现实情况是，Linux桌面系统并未将所有程序置于沙箱环境运行，且未来也无此发展方向。
既然如此，我的整个论点便不成立，而密钥环确实存在某些(次要)优势。
> DBus之所以混乱并非源于一两个问题，而是从底层设计起就布满无数缺陷。
这属于循环论证。D-Bus混乱是因为它本就混乱。即便我认同此观点，这仍是毫无意义的争论。
> 如果你希望对这些问题的解决方式产生影响，我们非常欢迎你亲自尝试改进DBus的现状。当然你不必这么做，但既然你对参与解决这个问题毫无兴趣，我实在看不出为何他人需要特别在意你对修复方案的看法。
我是在回应某位先贬低D-Bus又拒绝修复、转而另起炉灶的人。我不仅为D-Bus贡献了数十年心血，更是推动其在传统桌面Linux之外的商业部署的关键推手(至少十年前如此)。我的观点与他或你同样重要——那就是：毫无价值。
> 因为你根本不懂：这可不是Android。这里没有固定UID。
呃…我压根没提固定UID的事。
> 这里没有固定的绝对路径。
如果你的发行版这么规定，那就有。
> 二进制文件不总是root所有者。
如果你的发行版这么规定，那就是。
> 没有中央签名机构(谢天谢地！)
我的意思是，这在当下甚至算不上100%准确。哪个主流发行版不以某种形式对软件包进行签名？没错，二进制文件本身确实缺乏签名，但既然能对软件包签名，只要提供相应机制，对ELF二进制文件进行签名绝对没问题。
但无论如何。若你的发行版提供验证机制，它就存在。
> 你完全没搞懂：在桌面Linux环境中，通过PID验证的任何内容都毫无意义。
若你的发行版允许通过PID验证内容，它就存在。
关键在于机制因系统而异——就像OpenSuSE默认启用强制模式的MAC验证，而Arch可能没有。这才是桌面Linux的真实运作方式。你虽不受特定策略强制，但策略本身并非毫无意义。许多用户同时启用安全启动和锁定模式，这些措施绝非自动失效。
不可变发行版现已存在。
> 或者，若以Flatpak为例，只需禁止访问会话总线，转而仅允许访问经过过滤的总线——该总线仅支持与Flatpak提供的服务通信。这正是Flatpak的实现方式，从而规避了总线客户端认证的噩梦级难题。所有从原始Flatpak会话派生的进程树仅能访问此总线。
这根本解决不了问题。我通过Flatpak安装的软件有一半根本需要直接访问会话总线。
> 我实在看不懂这有什么意义。当然要让特权进程查看我的密码——这可是_我_的桌面环境。
你可知“最小权限原则”？我的打印机驱动虽属“特权进程”，但这不意味着它能截取屏幕并读取所有密码。若Linux采用能力机制会好得多。嘿，或许该有人尝试实现这样的RPC框架。
> 你描述的并非额外安全层，只是徒增复杂的无用设计。正如我所言，越是深思，越看不出这种不分享秘密的“秘密服务”有何存在价值。
那是因为你的思维固守单一方向，拒绝新输入。你始终在重复同样的论调。诚然，若要求现有桌面Linux环境在所有场景下都做到滴水不漏的安全，那确实无法实现。但这无关紧要。关键在于它能否作为构建更安全Linux桌面的基础组件？答案显然是“废话，当然能”。
重申：不可变发行版现已存在。它们本身就具备诸多必要的安全特性，你主要需要解决的是链接器行为的安全隐患。
> 你得出愚蠢的结论，比如必须设计一个键值数据库服务器，只允许原始插入进程读取数据——就像TFA所做的那样。为什么？到底为什么？？？直接部署多个完全隔离的私有实例不就行了！你明明已有现成的存储方案：应用程序的私有存储空间。这种场景根本不需要进程间通信(IPC)啊。
叹气
你难道不知道这正是当前众多应用使用GNOME密钥环的方式吗？它们纯粹用于存储自身密码，别无他用。这种机制早已存在。其初衷并非让系统共享你的密码，而是提供安全存储数据的机制。虽然有时也用于程序间数据共享，但我认为这甚至不是主要用途。
检查我的kdewallet时，可见以下应用程序：
– KRDC
– Remmina
– KRDP
– Chromium
– krfb
– xdg-desktop-portal
…以及“密码”文件夹，其中保存着SMB共享等场景的密码。
在这些组件中…我认为唯一可能被其他程序访问的或许是Chromium组件，用于浏览器迁移？其余组件仅用于自身存储。因此没错，钱包正被用作无智能的键值存储库——它会自动加密，无需应用程序进行密钥管理。
> 为何如此？你未说明原因。如今所有应用都采用这种方式，且从未需要过进程间通信(例如OpenSSL是库而非服务)。
并非指密码学本身，而是密钥管理。虽然通过提供密码学API也能实现代理式密钥管理，类似于利用TPM实现该功能的方式。这正是Windows系统中DPAPI采用的方案，与Linux和macOS的密钥环机制形成对比(后者从应用视角提供密钥值存储，应用本身既不执行加密操作也不管理密钥)。
而“为什么”的答案极其简单：你需要一个不会丢失的安全密钥。用户已拥有密码，因此它本身就是包裹密钥的完美口令；而应用程序无法访问该密码。如此一来，操作系统可自主决定用户数据是通过TPM加密还是使用口令包裹的密钥加密。这种集中控制机制在法规要求特定处理方式时可能至关重要。
> 这属于循环论证。D-Bus之所以混乱，正是因为它本身就是个烂摊子。即便我认同这点，这仍是毫无意义的争论。
这根本不是循环论证…老兄，你真该学着好好读懂文字。我的意思是它不仅混乱，更存在根本性缺陷。即便你将其清理干净，最终得到的也只是经过精心打磨的粪球。在任何逻辑世界里，这都不值得付出努力。
> 我是在回应某位先贬低D-Bus又拒绝修复它、转而另起炉灶的人。我不仅为D-Bus贡献了数十年心血，更是推动它在传统桌面Linux之外(至少十年前如此)实现商业部署的关键推手之一。我的观点与你或他的观点同等重要——那就是：根本不值一提。
至少你承认我此刻对你意见的重视程度，这点值得肯定——至少我们达成了一致。
但说真的，除了你是个油腔滑调的混蛋(抱歉，当别人这么对我时我从不客气)之外，我想强调的是：如果你希望DBus得到修复，那祝你好运。顺便说一句，我圣诞节想要颗Threadripper处理器。但请别对这样的人指手画脚——当有人正为Linux桌面这团乱麻付诸行动时，他们完全没必要理会你们这些看热闹的闲人，转而选择做点别的又有什么奇怪？
(说实话，Windows或macOS怎么做我根本不在乎。我关心的是Linux桌面本身，而非它和微软苹果推的垃圾软件相比如何。反正过去十年它们也没在桌面领域做出过什么实质性改进。)
有趣又可悲的是，这个问题早在80年代(最迟)就已解决。看看XDR和Sun RPC吧，它们既具备强类型API又内置版本控制。至于应用程序的认证机制，你得自己想办法——比如让它们发送cookie文件(描述符)。
这是我第一次听到有人讨厌D-Bus。我始终将其视为全局API总线——应用可注册其中，从而实现某种互操作性和自动化。毕竟它甚至能在Bash中调用，这有什么不好？
安全性问题也让我觉得有点可笑。毕竟普通桌面系统的大部分数据都存放在用户主目录，所有应用都能读取全部内容。这不能怪D-Bus。
更令人费解的是，Polkit竟未被提及一次。
当使用多个窗口管理器/桌面环境时，其架构本质上已然崩坏 https://github.com/dunst-project/dunst/issues/363
> 安全机制也让我觉得有些可笑。毕竟普通桌面环境中大部分数据都存储在用户主目录，这意味着任何应用都能读取所有内容。
世界正日益走向沙盒化应用(通过flatpak等技术实现)。正如原帖所述，这正是阻碍沙盒技术普及的因素之一。
几十年来每天都有沙箱逃逸案例。这种机制根本行不通。
>几个世纪以来每天都有开锁案例。这根本行不通
开一个锁需要时间，开两个锁则需要两倍时间。
无论逃脱1个还是10000000个沙盒，所需时间都相同。
这仅在讨论相同沙盒嵌套时成立(而这样做相当愚蠢)。
逃离两个不同的沙箱要困难数倍，而合理的沙箱选择并非易事——看看网页浏览器就知道了，更何况现实世界并非一个巨大的僵尸网络。
请关注varlink，这是SystemD生态中定义的D-Bus替代方案。
https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-
Varlink的诞生与systemd无关，SystemD只是后来采纳了它。只是在被采用之前知名度不高罢了。
不，特别是那个东西真他妈糟糕。DBus类型安全太差？那为什么不用JSON呢？对吧？对吧？！
你很少听到它是因为这并非热门话题。但厌恶情绪确实存在。
Dbus简直是糟糕透顶的烂摊子。想象一下Windows注册表——但它只能在运行时检查，包含可执行二进制文件，而且极其脆弱。
那些密钥库(gnome-keyring/kwallet)将密钥加密存储在磁盘上，因此所有应用程序都能读取加密密钥，但只有密钥库本身持有解密密钥。该密钥存储在内存中而非磁盘。
> 缺少规范？那就写一个。
即便作者提交规范，FreeDesktop-dot-Org也不会接受：
https://blog.vaxry.net/articles/2024-fdo-and-redhat
https://blog.vaxry.net/articles/2024-fdo-and-redhat2
这条评论让我困惑——难道让应用程序在沙箱中运行不是Linux桌面(尤其由Gnome/Fedora团队推动)的明确目标吗？Flatpak、xdg-desktop-portal和Wayland隔离机制正是围绕这个核心构建的。
或许现在正是重新构思的时候？如今IPC技术和高效可移植格式已相当成熟，如protobuf、flatbuffers等，而互联网的通用模型正是基于服务定位和组件间通信构建的。
我有点好奇，他们为何最初不采用Unix套接字方案，用内存中的命名管道来传输消息。
> 难道让应用程序在沙箱中运行不是 Linux 桌面(尤其由 Gnome/Fedora 团队推动)的明确目标吗？
没错，但文章作者忘了说明：他们的抱怨并不适用于沙箱中的应用程序，因为这些应用的 D-Bus 访问已被过滤。
我也从未用得顺手。和作者遇到的痛点如出一辙。
至于说它无处不在？没错，当年糟糕的SOAP技术也曾泛滥成灾，但那绝非好事…
关于密钥等问题…一方面，确实不必担心本地用户读取本地数据，但另一方面，将加密数据暴露在公共不安全的协议中实在愚蠢。解决方案是：需要安全性的应用程序，请勿使用D-Bus。
如果API设计得更严谨些(自文档化、不那么开放、减少冗余)，我同意同信任级别的应用共享访问是可行的。
真正的隐患在于网络上那些利用浏览器API读取本地存储容器的随机脚本。强制本地容器显式授权此类访问，并采用非D-Bus协议，才是更优方案——同时无需本地部署过度复杂的认证机制…
若非如此，我主要会修改的是：明确允许应用访问总线，而非让任何运行在内存中的随机程序都能访问…
暂且不论该帖内容是否正确。
究竟要重新发明什么轮子？
D-Bus(目前)无法读取你的思维，因此无法为你生成API，你仍需设计协议——只不过它是在D-Bus基础上添加特定特性与限制的方案。
2025年通过UDS实现相同功能既不增加工作量，也不会对终端用户造成负面影响。从可用性角度看，D-Bus没有任何独特之处是通过UDS监听服务无法实现的。
这相当于说，不用HTTP作为传输协议就是在重新发明轮子。
> 你讨厌a{sv}吗？若你提议用JSON替代，那可真够滑稽的。
或许你该关注Varlink——这个由systemd支持的D-Bus替代方案，它正是采用JSON协议。
关于密钥管理：
我的密码管理器通过执行命令行参数处理协议。任意应用程序虽可请求密码，但无法获取实际内容，更不可能从磁盘读取密码。
地精钥匙扣的设计确实不怎么样，但我觉得这种情况下协议本身倒不是什么大问题。
我可能太天真了，但为什么不采用浏览器的API开发模式呢？90%共享核心API，另设实验性API——过去几年里，似乎每个团队都能在不破坏用户体验的前提下推进代码开发，同时新想法源源不断涌现。
具体如何运作？我的意思是，这里的前提是：
“它他妈的管用”
能否对这个说法进行客观验证？
> 你们能不能别天天重新发明轮子？
不行，Linux桌面不过是让一群特殊雪花实现“愿景”的舞台——要么把小众需求强加给99.999%的用户，要么建立自成体系的小王国，好让他们自得其乐。
SecretManager或许值得额外关注，但我赞同。我们为此投入足够时间了，请别再分裂Linux桌面所剩无几的生态…
> 你讨厌a{sv}吗？若提议用JSON替代，
显然组件间应通过MCP通信。
你或许在开玩笑，但我认真认为这可能是不错的方案。即便存在缺陷，人人都支持的通用RPC/自动化机制，仍优于设计精良却无人问津的方案。调用MCP工具无需大型语言模型，任何编程语言都能实现调用。
我记得自己压根没提过要什么“总线”。
d-bus经常运行异常，至少在我这台不用systemd的机器上如此。
它已经够烦人了。
欢迎提供替代方案。
我认为systemd团队应该用Rust重写d-bus。这样我们就能把所有讨厌的东西集中到一个实例里了。
https://varlink.org/ systemd早就有
问题在于，varlink本是为缓解痛苦而生，而我追求的却是更深的折磨。不妨加入AI和MCP元素，在内核层级构建，并强制依赖sudo-rs。本地RPC还应基于区块链技术。
这简直像jwz的帖子，如果样式表模仿他网站的风格，我都会以为是他写的。
虽然D-Bus及其实现(常见的就不止一种)确实存在合理批评点，但本文完全避开了这些议题。读来更像是对系统协同机制理解匮乏者的支离破碎的胡言乱语。
这引发了一个显而易见的问题：为何不采用Wayland协议(通过独立于合成器套接字的通道)？该协议在多种语言中已有成熟实现，配备可编译的接口描述语言，况且所有GUI应用本就需要链接libwayland库。
(甚至COM接口也是可行方案)
vaxry与Drew Devault存在矛盾——后者曾当众揭露其编程之外的行径。
鉴于Wayland底层代码相当一部分出自Drew之手，vaxry拒绝触碰任何Drew编写的代码。
这项“协议”工作旨在进一步将Hyprland与Wayland基础设施解耦。
如同所有事情，这项努力再次源于个人私心与怨恨。
这正是我缺失的信息，我早知hyperland开发者声名狼藉，正疑惑背后隐情何在，感谢您揭示真相。
开源体验巅峰时刻
>当年编写xdg-desktop-portal-hyprland时，我不得不借助几个dbus协议(xdg门户运行于dbus)实现通信功能。查阅门户文档就能找到这些协议。
>[…]
>但没有任何应用——我再说一遍，他妈的没有任何应用——遵循规范。[…]
>有趣的是：这种情况至今未改！规范在SelectSources和Start中定义了“restore_token”字符串属性，但所有应用都置之不理，反而在“options”中使用“restore_data”。
错误。xdg-desktop-portal 同时提供客户端 API 和合成器 API。客户端 API 中该属性名为 restore_token[1]，合成器 API 中则名为 restore_data[2]。客户端不会直接与合成器通信，而是通过 xdg-desktop-portal 应用程序进行交互，后者再与合成器对接。属性名称不一致并不令人意外。
在文档中，面向应用开发者和桌面开发者的API在左侧区域[3]明确分开标注。这不仅与DBus无关(任何使用中间件转换消息的API都适用此规则)，更表明作者未尽到应尽的尽职调查义务。
[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/
> 属性名称不同并不令人意外。
令人稍感意外的是，xdg-desktop-portal 竟存在两个极其相似的 API，其差异既不明显又看似随意。初读文档时，我也曾困惑于这两个 API 之间的对应关系(或缺乏对应关系)。
我认为这番抱怨更多指向Gnome而非dbus。没错——其中充斥着大量“更糟即更好”(https://en.wikipedia.org/wiki/Worse_is_better)的设计理念。
默认实现(尤其是glib版本)确实糟糕透顶，sdbus的实现则干净利落得多。
所谓“人人可调用一切”的说法纯属谬误。总线策略机制本就存在，开发者若重视自然会定义规则。不过桌面开发者确实漠不关心——但这并非dbus设计的问题。
看看CORBA或DCOM吧，你肯定也不想要那种东西。
D-bus 破坏了最基本的预期：
当你能打开 xeyes 或 xterm 这样的基础 X11 应用时，理应能打开任何 X11 应用。
D-bus 打破了这个原则。
这让我的 Linux 系统感觉像是又一个“微服务失败”的案例。
> 当你能打开像xeyes或xterm这样的基础X11应用时，理应能打开任何X11应用。
我从未听说过这种说法。即便属实(听起来像是又个安全隐患)，对多数人而言X11早已式微。何必在意？
X11并未消失。我仍在使用，许多人同样如此。
能否指出你认为“X11消失”的依据？
绝大多数工作站已用Wayland取代X11作为默认图形系统。服务器本就不会安装X11。
对于约80%的桌面Linux用户而言，X11已“消失”。
(虽然仍可安装，但已不再是默认选项，且被标记为弃用/不再维护。)
我在x86-64桌面系统上运行OpenBSD，X窗口系统仍是主要支持的图形环境。
不过，这些圈子里对Wayland也颇有兴趣。
https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla…
由谁支持？Xorg服务器已停止维护。况且OpenBSD用户本就寥寥无几…即便所有OpenBSD桌面都转投Linux和Wayland，各项指标也不会出现显著变化。
OpenBSD同时维护着OpenSSH，其市场渗透率堪称惊人。
他们的ssh支持-X和-Y选项运行远程X应用程序。
等这些功能专为Wayland优化并支持新协议时再通知我。
在此之前，请安于这个微不足道且可有可无的小众群体吧。
将
-X和-Y选项集成到ssh(1)实属失策，这假设了所有人都在使用Athena/X11类系统。不过你可以结合waypipe和ssh实现相同效果(即waypipe ssh等同于ssh -X)。在这些选项被整合到OpenSSH之前，Wayland仍将处于少数派地位。
我不确定这个说法是否合理。
OpenBSD维护着自己的Xorg分支，名为Xenocara。
我的意思是讨论对象是Linux系统。即便将BSD用户群体纳入统计范围，我认为Wayland的使用率也不会低于80%。
我常看到这样的建议：若某功能在Linux上无法运行，就从Wayland切换回X11。
况且20%的用户基数相当可观。你这种说法无异于因“百分比”就宣称Firefox“消失了”。
相信我，X11并未消亡。
(本文通过运行于VNC会话的浏览器撰写，该会话底层采用X11协议)
“我常看到这样的建议：若某功能在美国政府系统中无法通过Chrome运行，请尝试IE6。”——去年这建议依然有效。
“相信我，IE6并未消失”——我
X已遭弃用。其维护者不愿继续维护，希望用户转用Wayland。
主流桌面环境已移除X代码路径，或将在未来一年内完成。工具包也将跟进。对新软件和非遗留软件而言，X已是死胡同。
这个死胡同却让我能在Ubuntu 24.04上使用HiDPI(即4K显示器)，并运行VMWare图形界面和OnlyOffice。
Wayland问世18年，至今仍无法在常见场景中流畅运行主流应用。
尽管随意点踩吧，我只是陈述所见。我不得不退而求其次使用X…
是否有确切数据支持80%的说法？我无法断言对错，只是持怀疑态度——因为我仍有应用程序在Wayland下运行异常(如Discord)，既然我遇到这类问题，其他人遇到也不足为奇。
这是多数主流发行版的默认设置。
仅支持Wayland(默认安装)：
* Fedora
* Ubuntu
* openSUSE
* Arch Linux
* Pop!_OS
默认支持Wayland：
* Debian
* SUSE
我每天都在Wayland环境下使用Discord，至少已有三年。AMD 9060与NVIDIA 4060(及AMD RX 580)均可流畅运行。
所用发行版对开箱即用体验影响巨大。
> * Arch Linux
Arch默认甚至不安装内核，它如何默认启用Wayland？
哎呀！抱歉我在列有变体的表格里操作时，可能误移了单元格！
Arch显然没有“默认设置”。Manjaro运行在X11上。
不过Steam Deck上的SteamOS确实使用Wayland。
Waypipe工具在Wayland环境下实现的X转发功能相当接近原生效果。:-)
我不明白为何需要“听说过这个”。如果像多数人那样在电脑上成功运行Linux，且xeyes或xterm能正常工作，我自然会预期其他X11应用也能运行。
要知道，在多数讨论中搬出安全问题往往是终结对话的捷径，但涉及进程间通信时，真正关心此事的人都清楚这是转移视线的幌子。
对我来说也几乎没问题，只是笔记本在Wayland下无法调节亮度。X11环境下可以调节。具体原因很复杂，但这就是简而言之的结论。因此在这些问题基本解决之前，像我这样的人至少还得依赖完整的X11环境。
我遇到同样问题直到更新修复了它
这类问题依然大量存在。
令人惊讶的是Wayland至今仍无法控制键盘指示灯(如滚动锁定键)，这导致依赖这些指示灯的非特权程序无法移植到Wayland环境。
即便我自己不依赖这类程序，也觉得Wayland让合成器只负责键盘的按键功能而不管理指示灯的设计很奇怪。
说到底他们最初是全面封锁，随后才逐步为现实世界应用开辟所需通道——毕竟用户使用计算机正是为了这些功能。这种从封闭环境逐步开放的策略或许优于初始开放后再封锁，但耗时漫长，部分用户可能因软硬件兼容问题被彻底排除在外。就我个人情况而言，Noveau似乎无法与显卡背光控制正常通信。新内核和驱动下的X11同样无法实现，但至少能通过伽马校正模拟暗屏效果。Wayland要么不支持伽马校正，要么该功能失效——具体细节记不清了。
我从未见过行为良好的D-Bus应用程序，NetworkManager尤其令人抓狂。
我正尝试用Connman替代NetworkManager的发行版。结果如出一辙——无论如何都无法连接，甚至无法识别手机的Wi-Fi热点。
我终止了connman服务并将其移出自动启动序列。我手动编辑了该死的wpa_supplicant.conf文件添加手机网络配置。首次尝试就成功了，之后每次都正常工作。
GNOME的创始文件名为《让Unix不再糟糕》，其作者(主要是Miguel de Icaza)的真实意图是“让Unix几乎完全像Windows”。D-Bus不过是系列尝试中的最新产物，企图将微软那套笨拙的对象模型强加于Unix领域——这个领域本由专注单一功能的C程序构成，通过文件描述符、管道和网络套接字相互连接。更荒谬的是，他们竟在COM原有缺陷之上堆砌了更多问题！
至少史蒂夫·乔布斯试图将Smalltalk风格的面向对象编程移植到Unix模型时，还具备远见卓识——他将Smalltalk的核心(以Objective-C的形式)一并引入。
你真在考虑dbus吗？它根本不在常规二进制加载路径里。况且事后来看，它与其他可能因各种原因导致应用程序无法运行的库并无二致。
> 推广的关键可能在于其他语言的绑定。这些库虽全部采用C++编写，但因设计之初就保持精简，对熟悉Rust/Go/Python的开发者而言，实现语言绑定应不难。
若协议设计如此简洁，请制定正式规范以供生成客户端代码。
C++绑定绝非我Go程序所需。
> 若存储库处于解锁状态，总线上的任意应用均可读取其中所有密钥
天啊。我虽然概念上知道是这样，但从未真正花时间思考过其影响。
基本上，只要你解锁钥匙串，所有秘密都会被任何能连接总线的软件访问到…这怎么能接受？难道我们只能用Flatpak运行所有程序吗？
有趣的是，我的工作 macOS 钥匙串总会莫名损坏，每次系统更新后都得重建。重建时系统会进入几分钟的特殊状态——所有需要访问密钥库的应用都会反复请求钥匙串密码验证。安全系数简直爆表！
结果发现，每隔几分钟所有应用都会重复此操作，其中许多应用甚至多次请求。应用程序需要访问刷新令牌才能下载邮件，或获取密码以实现网站自动填充功能。
我乐见Linux现状的诸多改进，但应用程序无需请求即可访问总线才是其可用的根本原因。
这种情况之所以被接受，是因为Flatpak D-Bus及其同类工具对普通“资深”用户而言过于晦涩难懂。问题确实存在，但整个系统架构过于复杂，除非真正理解整体体系，否则很难建立清晰的认知模型。
KeepassXC会在泄露密钥前进行确认
多数人会禁用该功能。
现实情况是没人愿意每次输入密码都被提示。用户想要的是自动填充。
人们对此的抱怨将边界设错了位置，而提出的解决方案又基于不存在的用户行为(他们绝对会点击“是，信任这个随机应用，我正忙着呢，请快点完成”)。
我不希望被反复提示。或许我需要分级权限管理，但即便如此要求也过高——你想要我的SSH密钥吗？嗯，我可能愿意授权给某个通过SSH自动化操作的应用。但等到作者交接后，还要再过5个版本更新，这些密钥才会被发往俄罗斯或其他地方。
> 这意味着当“/usr/bin/firefox”设置“passwords:superwebsite.com = animebooba”时，名为“~/Downloads/totally_legit.sh”的应用无法查看…
有趣的是它在此场景下如何处理符号链接。更具体地说，这个方案在NixOS系统上是否会彻底失效。
macOS密钥链访问控制列表依赖于请求密钥的可执行文件是否满足代码签名要求。
我猜它会追踪进程ID
进程ID每次执行都会改变。这在保存配置数据时有何帮助？
你是指实际路径而非进程ID吗？
我也讨厌D-Bus，同样厌恶JSON。文中提及的部分问题确实存在，但它还有诸多其他缺陷(例如Unicode处理可能引发问题，实际问题远不止于此)。文中提出的解决方案我也无法认同——虽然有所改进，但仍存在隐患。
更理想的方式是重新设计操作系统架构，即便在现有Linux系统中仍有改进空间。我认为将敏感信息置于消息总线并非正确的沙箱实现方式，全球性消息总线本身就不应存在(应限定于特定程序；若程序沙箱机制完善，可通过环境变量声明等方式限制其访问权限)。
现有沙箱系统同样存在缺陷：例如部分系统无法正确处理字符集，可能不支持以下功能：popen、通过程序命令行参数限制可读写文件等。
对于同一计算机上运行程序间的通信安全，加密算法可能并非理想方案；操作系统应承担安全防护职责，防止程序访问或篡改其不应接触的内容，除非配置允许，否则应阻断程序间通信。
关于数据格式，我可能采用DER(或对非规范化字段使用SDER，因规范化形式并非所有字段都重要，但某些字段可能需要)。
(具体实现可通过权限验证、直接阻断访问、将消息转发至可能修改/记录的代理等手段，阻止消息向未授权对象发送或接收；此类机制能增强系统灵活性。)
>当年编写xdg-desktop-portal-hyprland时
哈哈哈。早该猜到的。作为外行，我唯一接触过D-Bus的就是xdg-desktop-protocol。难道这个特定用例本身就特别… 讨厌？我猜此刻电脑里各种应用都在不知不觉中忙着D-Bus通信，但要让xdg-desktop-protocol配合wlroots运行，简直要画五芒星、翻人皮封面古籍。
这个总线能否为每个应用程序提供兼容D-Bus的“防火墙/翻译器”式D-Bus套接字(前提是它们正确使用D-Bus环境变量)？若能作为即插即用的默认方案而非运行两个总线，或许能加速普及进程。
众所周知，“Linux桌面元年”的呼声已持续多年。今年，随着微软自掘坟墓，Valve也暂时放下金钱池的浮华，致力于让所有软件都能在Linux上运行，这一愿景似乎即将成真。我目睹了由Cachy、Nobara、Bazzite等发行版驱动的用户激增浪潮。其中许多人毫无Linux使用经验，技术素养也普遍不高。
这让我深感恐惧。说得委婉些，Linux桌面系统的安全性根本不存在。而Linux桌面用户群体的文化更雪上加霜——至今仍盛行着“黑帮管理员”式的门槛把控，当新用户难免出错时便嗤之以鼻，最糟糕的是他们完全拒绝承认Linux桌面存在安全隐患。每当新用户询问该安装何种杀毒软件，往往遭遇嘲讽与讥笑——因为那些(老派)Linux用户真心认为自己的电脑天生免疫，永远不会被黑客入侵。
首批投入精力开发Linux勒索软件/窃取程序的网络犯罪分子必将掀起风暴，届时许多人将遭遇残酷的现实冲击。文中提及的D-Bus密钥漏洞，不过是Linux桌面系统设计缺陷导致的安全隐患之一。
当然存在重视安全的发行版，但我们并未看到新用户大规模迁移至Qubes系统。
注：此处并非针对上述发行版，三者均表现优异，安全性并不逊于多数发行版。
任何下载的Windows程序同样能窃取你的所有机密。默认隔离程序的操作系统仅存在于手机(及Chromebook)平台。
除非授予管理员权限，否则程序确实无法窃取(诚然，大量Windows用户默认使用管理员账户运行电脑)。此外，Windows用户通常至少会运行某种反恶意软件，虽然不完美，但对大多数泛滥式攻击的恶意软件确实有效。
编辑：经查证需更正，窃取工具确实已进化到无需管理员权限就能获取Windows上的多数凭证。
但“严格来说不比Windows差”，这难道就是Linux应追求的安全目标吗？
所有数据均归用户所有。运行程序时，该程序将访问全部数据——此时是否具备管理员权限无关紧要。
Windows的密钥管理机制相当开放：只要知道密钥，即使数据由其他应用存储，也能请求任何内容。虽然存在将密钥锁定至特定应用的方法，但多数Windows版本并未严格执行该机制。
唯一需要管理员权限访问的用户数据是沙盒化的Windows应用商店程序数据——即便是所有者也无法在程序外部直接访问，必须具备管理员权限。
我认为这忽略了Linux桌面安全的核心问题：用户本身。攻击者只需诱使用户运行InstallSteamWithAllGamesUnlockedForFree.sh——就像Windows世界的AnnaKurnikovaSexTape.exe那样。
这是教育问题，任何技术都无法解决。
即便dbus没有这个问题，“这是我的硬件，我自有主张！”——这才是Linux的精髓所在。
别说运行随机下载的shell脚本了，只需诱使用户执行curl some-url/do-some-cool-thing | bash就够了。
几乎所有组件都通过dbus通信，连浏览器扩展也不例外。
这比运行不可信shell脚本更危险。
这并非核心问题。真正的问题在于：若我能说服你运行我的脚本，便极易进一步诱使你授予额外权限，从而获取你的数据。当Cargo这类工具强迫我运行sh脚本时，实在令人恼火。正是Cargo之流让sh脚本运行变得过于普遍。
我猜你指的是rustup而非cargo本身？还是我理解有误？
是啊，刚才脑子短路了。
cargo 在后台构建/运行 build.rs
浏览器扩展？你是指像 Chrome 之类的？从未听说过这种东西
Plasma 集成和 Gnome-Shell 集成支持，这些都是开源的，你可以亲自查看。
密码管理器扩展(如1password和bitwarden)也普遍采用这种模式。
我原以为这类安全问题由AppArmor和SELinux处理(尽管可能无法实现对机密数据的精细访问控制)。所有桌面Linux系统都应启用其中一种机制，因为存在安全风险的组件远不止D-Bus。
我差点以为这是指德意志银行的中央市场消息总线(同样叫D-Bus)。真是回忆满满啊…
有人知道如何监控运行中A程序发送到Dbus的内容吗？我想重构并实现自己的A程序。欢迎提供任何可行的步骤。
据我所知，systemctl是通过D-Bus向systemd发送指令的。我读到过systemd实现了专属的D-Bus，速度比独立的D-Bus更快。
这让我产生了疑虑：
"你见过kwallet或gnome-keyring吗？没错，就是这些东西。它们本应是用于存储签名密钥、密码等敏感信息的’安全存储库’。虽然可以设置密码保护，但这真的安全吗？不，并不安全。这些密钥可能在磁盘上经过加密，理论上能防止笔记本被盗时信息泄露。若你此刻因“磁盘加密已有二十年历史”而感到不适，你并非孤例。但最糟糕的是：只要存储库处于解锁状态，总线上的任何应用都能读取所有密钥。不，这绝非#%&@玩笑。一旦输入密码，所有应用都能悄无声息地读取全部密钥。"
那么，systemd如何确保D-Bus命令不能来自无特权账户？
systemd的D-Bus实现是否采用了与独立D-Bus不同的安全架构？
我承认对这些机制一无所知。
https://www.reddit.com/r/linux/comments/1lxd0hl/systemctl_vs…
systemd 通过系统总线接收命令(即以 uid 0 运行的 dbus 实例)。用户桌面拥有独立的会话总线，该总线以用户身份运行。
感谢说明，这很合理。
但对于用户级 systemd 而言，这意味着总线对任何使用用户凭证运行的二进制程序开放。
不过这风险并不比运行 ssh-agent 更严重。
polkit
这篇帖子彻底浇灭了我对 hyprland 的兴趣。
dbus 实在令人抓狂：没错！
但眼前这番论述根本无法说服技术人员——纯属人身攻击。既无链接也无参考文献，只是断章取义地拼凑内容，竭力将问题描绘得最糟糕。
dbus明明设有策略！GNOME开发者并非主张“取消安全机制”，而是强调："请使用现有的安全边界！启用允许列表！拒绝列表！但正如本文所有论点，没有任何超链接、参考文献，无法深入了解真实情况：这纯属恶意攻击，目的不是传递信息、澄清事实，而是刻意遮蔽问题本质。
这种行为简直垃圾，我绝不愿参与如此堕落、误导、欺诈的生态系统。每条指控都在扭曲掩盖复杂真相，远非揭露弊端。
成百上千的人即将加入这场黑暗的十字军东征，跟风举起火把。他们基于对整体局势极其片面的误解而行动。这篇帖子是恶毒的祸害，理应被隔离封锁。
我从未认真对待d-bus，因为据说更新dbus时不能简单重启守护进程，必须强制重启系统。
将操作系统调用置于总线之上。我认为需要为大多数用户空间API添加权限机制，这样应用程序就不必为安全起见被沙盒化在虚拟机中。这难道就是安全增强型Linux(SELinux)的实现方式？但我有时希望权限由用户授予。例如，除非用户明确指定文件(可通过GUI交互实现)，否则程序不应访问文件；若更进阶些，当用户在命令行输入文件名时也应允许访问。希望我的想法能说得通：通过普通用户输入来控制系统访问权限。这种方案是否可行，还是我梦想太远大？
我认为实现方式应基于能力的安全机制。不过这种方案更适合全新操作系统设计(出于某些原因，也适用于计算机架构设计)。
对于Linux系统，我们可采取其他方案，尽管类似方案或许可行。但seccomp似乎不支持发送接收文件描述符的功能，也无法等待某组文件描述符中的任意一个(如“select”函数)，因此其功能相当有限，需要额外进程代理所有这些功能。(维基百科指出seccomp还会禁用RDTSC；而我的系统设计根本不会包含这类功能，因为我希望限制所有I/O操作——包括高精度计时；同时也会限制CPUID等功能。)Capsicum或许更优，至少对BSD系统而言(虽然我不确定它是否禁用RDTSC或CPUID)。
我曾构想开发一个沙箱库，它不应需要对程序进行大量修改(尽管仍需部分调整)；该库可用于指定涉及文件操作、popen调用、命令行参数、网络功能、计时等所需权限，并提供请求不同字符集输入的功能，以及请求文件名、连接互联网时的主机名和端口号等其他信息的功能。
这与macOS通过“透明性、同意与控制”子系统实现的机制基本一致。即便是未沙盒化的应用，若试图访问我的桌面，系统也会弹出提示框征得用户许可。
MQTT能否成为新型桌面总线的基础？至少能承担半数职责。它虽未涵盖所有细节，但作为基础架构难道不够吗？
MQTT解决的是传输层问题，这本就不是核心难点。除此之外它毫无建树。
有时我感觉直接借鉴安卓部分功能比重新发明轮子更省事。
> “人人皆知D-Bus”
直到今天我才初闻D-Bus。
深表同感，但联想到XKCD关于标准的漫画：https://xkcd.com/927/
> 每次出现新实现时总有人引用这幅XKCD漫画。但这次情况并不完全相同。
呃…其实完全一样。
这是我编译Emacs时最爱的D-Bus配置：
这样用好几年了，经历过无数Emacs版本，没有D-Bus也一切正常[TM]。
DBUS -> 垃圾COM
SystemD -> SVCHost.exe
Iproute 2 -> 你喜欢netsh.exe吗？
Gnome 3, 4 -> 模仿Windows 8的玩意儿
Mono -> C#的道路建设工具
GConf -> Windows注册表；天啊，dconf-editor和gconf-editor简直如出一辙
真期待Gnome里出现MMC.exe和GPO编辑器
我本以为替代方案会集成到systemd里。
哪个方案？:)
我其实期待bus1，设计太棒了。
结果看来要用varlink了。呕。“json json鸡蛋培根和json”
systemd-busdd(读作“busted”)
用Rust编写，还贴心地附上MIT许可证。
你是说这个？https://rust-for-linux.com/android-binder-driver
我倒不讨厌它。以前我讨厌systemd，但如今它已成为我最爱的Linux组件之一。
已有类似方案：Varlink(https://varlink.org/)。其核心理念与本帖发起人所述基本一致。
可能很快就会实现。:)
systemd-bus 2.0
补充一点：D-Bus 支持自动启动的通用服务概念，例如 org.freedesktop.FileManager1。当向该服务发送命令时，若文件管理器未运行则会自动启动。但系统未提供用户选择启动文件管理器的机制，因此若同时安装了KDE和GNOME环境，启动Dolphin或Nautilus的概率各占50%。例如参见：https://unix.stackexchange.com/questions/778028/set-a-specif…。这实在令人费解。
D-Bus 本身并不支持通用服务概念。尽管它并不适合此用途，人们仍在利用 D-Bus 实现通用服务的自动启动。这完全是两回事。
虽然可以在 D-Bus 基础上构建可行方案，但显然至今无人尝试。
又一个被审查的标题。
> 当初编写xdg-desktop-portal-hyprland时
啊，没错，XDG“门户”。每次安装新的Linux/Wayland系统时，文件选择和屏幕录制功能都会失效，迫使我不得不研究十几个不同实现方案中支持、半支持、已损坏和未支持功能的疯狂矩阵，然后想出让系统正常工作的魔法配置咒语。真是绝妙的设计。但它很安全！
> 正因如此，我决定亲自动手。我正在编写新的总线协议。
哦，太棒了。作者引用xkcd/927的漫画，仿佛预见了这种回应，而这恰恰完美契合当前情境。
> 例如在Wayland环境下，一旦切换就意味着放弃X。你无法同时运行X11会话和Wayland会话——这根本不符合其工作原理。
咦？我用niri时，为了让某些应用正常运行，不得不同时安装Xwayland和xwayland-satellite。我根本搞不清它们各自的作用，更懒得探究，但听起来像是某种X兼容层。请多说说X和D-Bus有多糟糕吧。
几个月前我转投Wayland阵营，如今系统基本稳定运行令人欣慰。但Wayland开发者似乎热衷于重复造轮子——这篇文章的抱怨就暴露了他们的优越感，大家对彼此的方案都嗤之以鼻，总想为特定场景重构生态中所有现成工具。典型例子：那些以
hypr开头的工具。现在看来还得加上“tavern”——管它是什么玩意儿。我厌倦了现代Linux的发展现状与方向。真希望自己能用OpenBSD摆脱这永无休止的动荡与争吵。
编辑：啊，看来作者也认同我的观点：https://blog.vaxry.net/articles/2024-linuxInfighting
他们指责他人行为恶劣，鼓吹建设性批评，自己却在重蹈覆辙。荒谬至极。这些家伙怎么能当上Linux社区的领袖，我实在想不通。
> 推动产品进步的关键在于协作。
百分百赞同。或许他们该听听自己说的道理。
> 啊，没错，XDG“门户”。正是这个玩意儿导致我每次安装新的Linux/Wayland系统时，文件选择和屏幕录制功能都会崩溃。迫使我不得不研究十几个不同实现方案中支持/半支持/已损坏/未支持功能的疯狂矩阵，最终摸索出让系统勉强运行的魔法配置咒语。真是绝妙的设计。不过它很安全！
有没有办法通过替换某个.so文件来规避这种混乱(以及XDG门户和其他XDG组件的问题)？我对具体实现机制了解有限，不确定这种方法是否可行。(或许对某些程序有效，取决于它们为此目的使用的库。)
我对原理仅有模糊认知，但认为没有替代方案。使用Wayland时，要么依赖发行版或桌面环境自动配置，要么手动操作。
公平地说：门户机制的理念本身未必糟糕。但各种半吊子的实现方案各自为政，整体用户体验实在糟糕透顶。
嗯，屏幕录制功能终于在我这儿正常工作了。真是历经波折啊…
哦，我这边也正常了。但除非你用的发行版或桌面环境已预配置好，否则必须手动设置。我在Void Linux上习惯了这种操作，通常不介意，但这种糟糕的用户体验在X11时代根本不存在。
[已删除]
我们需要的是协议而非具体实现，语言细节本不该成为关注焦点。它应当让库开发者能轻松用多种语言实现，也让应用开发者易于使用。设计时应兼容所有操作系统，即便当前并非所有平台都支持它。
实际上我们可能需要两者兼备：稳健的协议与优秀的参考实现。
Wayland最初主要被宣传为协议层面的创新。近二十年过去，它仍未能实现完全替代Xorg的目标，且可能永远无法达成——Wayland开发者明确表示“这并非我们的目标”。人们花了相当长时间才意识到这一点；虽然近年已逐渐明朗，但十二年前鲜有人理解其本质。
至今我仍未能找到能替代所有Xorg功能的解决方案——例如ImageMagick在Wayland上的运行机制就截然不同。或许日后会再次尝试，但先前的工作成果已失效，替代方案要么已弃用、要么效果不佳、要么功能残缺——对于曾被高调宣称“这就是未来”的技术而言，这实在令人沮丧。
完全同意，我本该用更中立的措辞。理论上规范文档就足够了，但实践中可靠的参考实现能消除歧义，还能揭示规范中的问题。
这代码才一千行不到。你自己动手做有什么困难？
若选用正确编译器，C++是内存安全的
并非所有人都愿意为获得安全性而用filc重新编译整个应用及依赖项——这会导致运行变慢、额外占用内存。该方案的存在固然不错，但推广时刻意忽略这些权衡取舍就显得奇怪了。
没什么奇怪的。
只是指出事实：不安全的不是语言本身，而是你选择的实现方式
根本不存在“安全的”编程语言。
HQ9+
> D-Bus约20年前由GNOME团队推出。相较于已有40年历史的X窗口系统，这个仅诞生20年的软件竟同样糟糕得令人惊讶。
这不足为奇。比如systemd的作者如今效力于微软。突然间，Linux生态系统中所有这些变革都显得合情合理了。它已彻底沦为企业商品，从头到尾。当企业化成为目标时，统一系统便显得合乎逻辑——即便它糟糕透顶。
我向来直言批评微软，但systemd/wayland堪称Linux最重大的进步之一。若能改进它，请尽管推出更优方案。
解决什么问题？除了具体实现细节，人们甚至可能质疑问题定义本身及解决方案的覆盖范围。当然，我们可以自由实现替代方案来处理DNS解析、进程间通信、日志记录、时间同步、任务调度、服务监控等等…但所有这些功能是否应该由单一解决方案同时承担？
你提到的所有功能都相互依存，因为资源与服务管理才是核心。我确信他们最初试图设计最小化范围的方案，但随后发现与那些历史悠久但成熟的开源软件对接极其困难。
我非常感谢systemd不断拓展功能边界，因为许多问题的“通用”替代方案虽稳定，却常在配置、维护和调试方面表现糟糕——其非默认场景下的易用性仍有巨大改进空间。更何况，若维护者对你所需的改进置之不理，你又能如何让软件具备未来数十年的生命力？我多次分叉项目并尝试重构技术债务，只为避免新功能实现时让代码变得更臃肿。完成这些工作后，你往往只想删掉所有代码，用“正确”的架构从头开始。
因此我能理解systemd开发者的立场，他们承受的技术层面的痛苦已足够巨大，更不必说邮件列表中与某些人激烈的争论了。
开源项目蕴含复杂的社会动力学，总会吸引某些人争当“领袖”或维护者——即便他们的技术能力远不及我期望的水平。我曾痛苦地向某些人解释安全漏洞，理想主义的开源治理幻想就此被现实狠狠击碎。
更何况systemd的文档质量确实出色。
它本质上并非单一解决方案。systemd不是单个软件，而是由约20个组件构成的系统。
认为初始化系统包揽所有功能的人，显然连最基础的研究都没做过。当然，命名方式或许也难辞其咎。
没错，我本不该删掉先前的回应：解决方案由不同组件构成是理所当然的，多数事物皆如此。人们当然明白这些内部组件可被替代为执行相同功能的新组件，但当争议焦点在于整体解决方案的范围与目的时，这种认知毫无助益。
没错，我的意思是根本不存在所谓的完整解决方案。这纯粹是项目命名规范问题。
比如 systemd-boot 与 systemd 毫无关联。完全无关。它只是借用了项目名称。这确实容易造成混淆。
谁提过初始化系统的事？
当人们指责systemd违背Unix哲学、是个庞大的单体系统时，通常就是指这种情况。但这根本不是事实。根本无需争论——systemd由众多专注单一功能的软件组件构成。
我们讨论的不是“人们通常何时”，我们身处这个子讨论串，而你才是唯一在此提及初始化的人。
他们现在在何处工作…其实与项目无关
> 2010年，当时任职于红帽的软件工程师Lennart Poettering和Kay Sievers[2]启动了替代Linux传统System V init的项目[16]。
https://en.wikipedia.org/wiki/Systemd#History
> 当时在红帽工作的软件工程师Lennart Poettering和Kay Sievers最初开发了systemd
此处有误，Kay Sievers当时任职于Novell/SuSE，详见https://0pointer.de/blog/projects/systemd.html#faqs
关于本次讨论的说明：您的修正已添加至“讨论页”——能否建议您直接在主页面进行相应修改？
(主要基于两点：1)我认为未来几千年…讨论页都不会被关注；2)既然您已确认错误并持有证据，理应由您完成修改)
感谢添加说明，但因未注册账户无法编辑维基百科。但愿有人能注意到。