首页科技快讯这两位程序员大神“打”起来了，发生了什么？

这两位程序员大神“打”起来了，发生了什么？

来源：晰数塔互联网快讯时间：2021年01月22日 15:36

本文来自微信公众号：InfoQ（ID：infoqchina），编译：核子可乐、Tina，原文标题：《程序员大神JWZ和Linux Mint干起来了：两个熊孩子引起的“口水”大战》，头图来自：视觉中国

两个孩子在父亲的电脑上玩耍时，不经意间发现了一种能绕过 Linux 屏保程序并锁定系统的方法。这是个漏洞，可能允许恶意攻击者绕过操作系统的屏保程序及密码，访问本应锁定的桌面。

一位昵称 robo2bobo 的用户在 GitHub 上的 bug 报告写道，“几周之前，孩子们打算访问我的 Linux 桌面。而我就站在他们身后，看着他们到处乱按乱拍。”两个孩子在物理与软键盘上同时按下随机按键，最终导致 Linux Mint 屏保程序崩溃、他们得以直接访问桌面。

这位程序员爸爸很惊讶，于是他让孩子们再试一次，没想到居然成功了，“我本来以为这只是个偶然事件，但孩子们后来又把问题重现了。”

当天晚上，他到 Linux Mint 的 GitHub 页面上反馈了这一 bug。没想到的是，马上就有其他网友表示在同样的桌面环境下，“他的孩子”也遇到了同样的问题......

Linux Mint 首席开发者 Clement Lefebvre 经过一番研究，表示：“这是一个高优先级的错误，需要尽快修复。”

一、Bug 来源：OSK 上的Ē键

最开始，开发人员花了一天多时间，想复现问题，但实际情况并没那么容易：“自昨天以来，我们一直无法在此处重现崩溃。”

网友想象开发人员如何试图重现错误

根据 Clement 的介绍，问题最终被归因于 libcaribou，即 Linux Mint 中使用的桌面界面 Cinnamon 所随附的软键盘（OSK）组件。具体来讲，当用户按下软键盘上的“ē”键时，此 bug 即会被触发。

在大多数情况下，这个 bug 应该会导致 Cinnamon 桌面进程崩溃；但如果在屏保程序下打开软键盘，则 bug 会引发屏保崩溃，于是用户即可访问底层桌面。

Lefebvre 表示，去年 10 月 Linux Mint 系统曾着手修复 CVE-2020-25712 漏洞，却在不经意间引入了这个新的 bug。从那时起，所有使用 Cinnamon 4.2 以及更高版本的 Linux Mint 发行版都会受到这一绕过攻击的影响。这是因为从 Cinnamon 4.2 起，系统开始将软键盘功能添加至屏保页当中。

二、程序员大神 JWZ：I TOLD YOU！

关于这个 bug 的讨论，吸引来了杰米·扎温斯基（Jamie Zawinski），对此他专门发表了一篇文章，表示他 17 年前就警告过 Cinnamon 和 GNOME 官方：

“如果没有在 Linux 上运行 XScreenSaver，那么可以你的屏幕就相当于没有锁定。”

文章配了一段闪瞎眼睛的“I TOLD YOU”视频

出生于 1968 年的杰米·扎温斯基，英文简称为 JWZ，是《黑客帝国》中 MATRIX 矩阵的设计者。

他同时也是 Netscape 浏览器的主要设计者，出生于匹兹堡，中学没有毕业，就已经是一个天才程序员，15 岁开始在卡耐基梅隆大学做 Lisp 研发。90 年代初，他去了加州，加入著名的网景：“早在你听说过 Netscape 之前，我就已经负责开发 Netscape Navigator 1.1 的 UNIX 版本了。”

2004 年，JWZ 首次警告说他遇到了 Linux Mint 的漏洞，之后每隔几年，JWZ 都会遇到此类 bug。每出现一次，就吐槽一次。

CVE-2019-3010，从 Oracle Solaris 屏幕保护程序可以获得特殊权限升级；

CVE-2014-1949， MDVSA-2015：162：在 Cinnamon 屏幕保护程序中按菜单键，再按 ESC 键，就可以进入 shell；

按住向下键，解锁 Cinnamon 屏幕保护程序；

按住回车键，解锁 GNOME 屏幕保护程序。

JWZ 说，早在 17 年前，他甚至还准确提到过这个崩溃 bug，用来解释“如果不按设计思路操作，会发生什么问题”，可是每次 Linux Mint 都回复说“已经修复了”。

JWZ 认为，“糟糕的安全性比没有安全性还差”，因为现在的 Linux 图形化界面根基 X11 存在着不可修复的严重问题：锁定和身份验证是操作系统级别的问题；X11 体系结构的这一错误永远无法修复。

最后还说：“我很关注他们打算如何解决这个问题。”

三、Linux Mint 还击：你行你上，别 BB！

虽然 Linux Mint 在本周三发布了相关补丁，可以解决此项 bug 并有效预防潜在崩溃，但 JWZ 所说的话，可气坏 Lefebvre 了。

看热闹不嫌事大的网友，之前特地将 JWZ 的博客网址发到了 GitHub 的 bug 报告下，还 at 了相关维护人员。

Lefebvre 在 GitHub 页面上回应 JWZ：“写篇文章大加嘲讽没有任何意义。我建议你把自己的口嗨变成行动...... 我希望你能在真正参与工作的 6 个月之后再写封邮件，告诉我们‘这里还有问题，原因是一、二、三……’，或者直接给我们设计出一套又美观易用、又安全稳定的 locker。”

然后逐条反驳了 JWZ 的批评：

早在 2004 年，也就是 17 年前，我已经在文档中解释过自己在 XScreenSaver中做出的设计权衡。我甚至还准确提到过这个崩溃 bug，用来解释“如果不按设计思路操作，会发生什么问题”。

老哥，要让别人重视你的意见，还是得更务实一点。这就像我 17 年前提醒你“别出门，可能会遇上车祸”。到了真出事的时候，再告诉参加葬礼的朋友们“我早跟他说过了”。问题是，讲这些有意义吗？该出门还得出，该上高速还是得上，生活本来就没那么安全。用户只是想要漂亮的屏保，我们也在努力满足大家的要求。这里要请 JWZ 老兄想想，要在设计中把安全性与丰富性结合起来究竟有多困难。我们早该在设计中考虑这个问题？对，漂亮话谁都会说。重点在于，当时我们的目标是给用户提供漂亮的屏保，哪顾得上那么多？

哪怕是 light-locker 与 KDE 本身，在实际效果上也比 JWZ 的设想更靠谱，至少其在满足安全保障的同时，为用户需求给出了一种解决方案。我们最初发布 light-locker 时，并没发现这类问题。因为当时我们大多使用 gnome-scrensaver 及 mate-screensaver 替代 xscreensaver。换句话说，我们接受了 xscreensaver 存在安全缺陷这个事实，并在发布 light-locker 时几乎忘了这回事。很遗憾，bug 就这么被保留了下来。

而在编写 cinnamon-screensaver 时，本意是用它来替换掉 gnome 屏保程序。很可惜，我们还是没想起修复 bug。毕竟那时候我们连 light-locker 都没考虑进来，更何况是 xscreensaver 呢。于是乎，就引发了这次的问题。

其实这类问题总会出现，反反复复出现。

这就是现实，不管接不接受，这就是现实。JWZ 老哥好像不太明白这一点——你不可能禁止人们做自己想做的事儿，比如出于安全考虑不让他们过马路。哪怕有人总在提醒，除了让他们心烦之外，不会对交通安全有任何帮助。

每次 bug 出现，都回复说“这的确是个 bug，但他们已经修复了”。这是不对的，问题是这不应该是个 bug。真正的原因是系统设计的问题。设计系统安全架构的人，不应该采取让安全失效的方式。这是不合理的。

可以看到，GNOME 团队已经从头开始进行项目重写（我不太清楚他们在重写阶段用了什么设计），我们也有类似的计划。没错，我们犯了前人曾经犯过的错误，最后问题出现给了我们当头一棒。但纠结于过去真的没什么意思，最重要的是怎么避免问题再次出现。我们决定在开发路线图上把欢迎程序和锁定程序区分开来，这一点将在 5.0 版本中有所体现。

极尽嘲讽之能事的博文确实容易吸引眼球，也能让我们意识到问题所在。但我们的关注重点永远应该放在代码本身（不只是 gnome-screensaver 或者其他已经发布的上游代码，而是整个项目中的代码），有了问题就做做审核，项目不就是这么发展完善的吗？

JWZ 虽然提出了问题，但没有给出任何解决方案。就个人来说，我认为无论是在安全层面还是功能层面，light-locker 与 KDE 应该都是目前最好的方案选项。

出于种种原因，这个 bug 会在其他屏保锁定程序中不断出现。编写安全代码其实非常困难，大部分开发者其实根本不做不到。锁定与身份验证都是操作系统层级的问题。X11 架构中的这个问题永远无法修复。我得承认，这些 bug 值得高度重视——因为安全性差比没有安全保障还可怕。

我对以上内容深表赞同。

更让人生气的，在于开发 XScreenSaver 锁屏程序毫无乐趣可言。我一点兴趣也没有，添加这项功能单纯只是为了满足用户需求。

其实大多数朋友都像我一样，都不愿亲自参与安全保护工作。作为开发者，谁不想弄点酷炫的功能出来呢？而安全实际是在束缚自己，一个个查缺补漏，防止恶意人士破坏整个系统。这很重要，但没有乐趣。

XScreenSaver 是个了不起的项目，帮助用户解决了现实需求。作为其 fork 的 gnome-screensaver 也是一样，多年来始终服务于用户群体。所以虽然曝出一些安全隐患，但项目开发者已经明确解释了他们为什么要做出这样的选择与权衡。所以我觉得没必要抱怨——发现了问题，就解决问题嘛。我们还会更进一步。JWZ 的反馈对我们来说相当于一股反向推进，也更坚定了我们“如非必要，勿增实体”的基本开发理念。

但我还是想对 JWZ 老哥说一句，单靠说漂亮话解决不了实际问题。最好的办法，就是我们携手建立一条最安全的道路。是的，不要抱怨、别总强调什么“我早说过”，加入到代码审计中来、加入到功能开发中来，做个能解决问题的人。