一篇标题耸动的博客文章,又把 Basecamp 创始人 DHH 主导的 Linux 发行版 Omarchy 推上了风口浪尖。作者「One Happy Fellow」的结论很干脆:如果你在乎电脑安全,请不要用 Omarchy。理由是 4.0 版本里那些"可预见"的漏洞——视频标题能注入 bash 命令,系统通知能执行任意脚本。
DHH 随后在 X 上高调展示安全团队的修复清单,被博主怒斥为"营销变成了撒谎"。但把时间线拉长、把清单补全之后看,这事没有博主写得那么简单,也没有 DHH 宣传得那么体面。
十一天,从"年度桌面"到八类漏洞
Omarchy 4.0(代号"Quattro")在发布时的核心卖点是桌面组件重写,主打"开箱即用"的体验。十一天后,官方就推出 4.0.1,changelog 写得很直白:这主要是一份经新设"Security 团队"审查的安全修复合集。
被博主点名的两个案例确实存在:一个是 yt-dlp 抓取的视频标题里藏着换行符,能在 mpv 通知点击时被解析成命令;另一个是通知点击动作原本靠拼接字符串生成 shell 命令,现在改成了更安全的参数传递方式,官方说法是"关闭了一整类远程代码执行"。
但博主只讲了这两个。完整清单还有至少六类:主题包可执行代码、USB 设备名被当成 Hyprland 的 Lua 脚本执行、git 插件的传输 helper 不安全、FIDO2 鉴权文件路径可预测、默认把用户塞进 docker 组、agent 启动器权限过宽。规模比原文暗示的"一两个 bug"大得多。
没有 CVE 的安全公告,说明了什么
这里有个原文完全没提的关键信息:截至发文,Omarchy 的 GitHub 安全公告页面显示"无已发布的安全公告"。八类问题都是靠 PR 描述披露的,没有走 CVE 编号、没有走正式的 Security Advisory 流程。
这件事本身是中性的——很多发行版级项目确实不走 CVE 路径,不算行业丑闻。但结合"11 天从 0 到 8 类问题"的速度看,更像是内部流程仓促补上漏洞,而不是一套成熟的安全披露机制在运转。
另一个原文回避的事实:这些漏洞多数需要用户主动交互才能触发——点开恶意通知、装第三方主题、插入特定 USB 设备、看一条被篡改的视频标题。不是开机联网就会中招。这削弱了"但凡在意安全就不要用"这种一刀切建议的说服力。
- 风险.漏洞规模比原文暗示的更大,但触发门槛也比原文暗示的更高,两头都不该被简化。
骂错了没有,但也没说全
Omarchy 这类"opinionated"发行版的通病,是把体验打磨的优先级排在了代码审查前面。大量 bash 脚本堆出流畅的开箱体验,处理视频元数据、通知内容、USB 设备名这些不可信输入时,却没人真正审查过。这不是 Omarchy 独有的病,是所有靠社区脚本和 AI 辅助编码堆功能的项目共同的软肋。
体验跑得越快,安全审查往往落得越远。
DHH 的应对也值得单独看一眼。新设"Security 团队"、11 天打出一轮补丁、在 X 上高调展示成果——这既可以理解为对批评的快速实质响应,也可以理解为一次危机公关。两者并不矛盾:一个项目完全可能同时做对了修复速度,又在叙述上避重就轻。DHH 展示了修复清单的长度,却没有正面回答"为什么这些问题一开始就存在""为什么不走 CVE"。这才是真正被回避的问题,不是漏洞本身。
金玉其外的说法用在这里不算过分——营销一直很亮,但代码审查这一层,明显没跟上营销的速度。
对普通用户来说,判断标准很简单:装了 Omarchy 就该第一时间升级到 4.0.1,别装来源不明的主题包,别在系统层面随手点通知里的链接。对企业 IT 来说,"是否将其列入禁用名单"这个问题,答案不在于漏洞数量多不多,而在于这个项目有没有开始走正规披露流程、有没有引入外部审计——这才是下一次版本发布时真正该盯的信号。