@Jirajine #82
真无语，看来我说的又没有让你理解。

怎么又回到了之前的原点呢，我说了，需要安全更新不代表需要一直升级。

我前面的例子已经说过了，我已经在 5.1.1 停了，没继续往 6.8.x 版本继续升级了，你知道了吗？看到了吗？ 5.1.1 ，不是 6.8.x 。不过我估计你还是没看到。

你要是还不理解我说的什么意思的话，估计之后你也无法理解了。

@Jirajine #71
@adoal #74
我觉得我说的已经很直白了，因为 @Jirajine 通过强调浏览器有多么多么 security critical ，从而得出"浏览器需要不停升级"这个结论，所以我说他把安全更新和其他功能性更新混在一起。我也举了例子了，如果一个包 在 5.1.0 版本 存在严重的 security 漏洞，那么我只需要更新到任意一个没有这个严重漏洞的版本，从而停止继续升级，而不需要继续升级到 6.8.1 ，更不需要再未来出了 7.0 的版本继续升级。

看到了吗？我在 5.1.0 升级到 5.1.1 以后已经修复了严重的安全漏洞，我就已经停止更新了，这意味着不需要继续升级了。
我已经停了，可能你们还没看到我停在这里，我举下手✋，看到没，我停下来了。here here ，I am at 5.1.1 now.

总结上面的，说明 security critical 这一点，根本无法作为一个包"必须要一直升级的程序"的理由。这也是我举其他几个软件的原因（内核，各种服务器）。

现在知道我说的什么意思了吗？

@Jirajine #63
我不知道我需要说多少遍，安全更新不是功能更新，你偏要把二者混淆。
backports 和 security 也是两个东西。https://help.ubuntu.com/community/UbuntuBackports ，backports 的目的是给旧版的 ubuntu 提供新版的包，而不在与修复其中的安全漏洞。

我根本不知道你口中所谓的“大部分的安全漏洞根本没有 CVE”这句结论怎么来的。如果一个漏洞或者 bug 根本不重要，那么没有 CVE 也很正常。但如果是严重的漏洞，肯定会有 CVE 。而不重要的 bug fix 不会作为安全更新被推送也正常。

# 12:
> 因为浏览器是必须要一直升级的程序

# 40:
> 浏览器是 security critical 的，你不会想运行没有安全更新的浏览器访问一个网站直接被 RCE 。

我再重复一边，一个包我需要安全更新，不代表我需要一直保持到最新版本。一个包 5.1.0 的版本存在严重安全漏洞，我只需要 5.1.1 的版本，或者是 5.2.x 的版本修复这个漏洞，不代表我就一定要更新到 6.8.1 。

@Jirajine #40
安全补丁不是功能性的补丁，不是要求你一直不停的升级到最新版本。浏览器自然也不需要一直升级，而只是在必要的安全漏洞出现时才更新。否则内核也是 security critical 的，你难道想运行一个有提权漏洞的内核，让随便一个普通用户都能随时提权为 root ？各种服务器（ sshd/nginx/apache ）也是 security critical 的，总不可能一个服务器存在 RCE 随随便便让人黑进来？

我前面已经说过，LTS 的目的就是保持系统不升级，但依旧接受必要的安全布丁。这些必要的安全补丁是通过 security 源给你推送的（比如 noble-security/jammy-security ）。既然 LTS 里带一个 S 当然是指厂商提供支持（ Support ），并且还是能维持较长的时间（ Long Term ），不然怎么叫 Long Term Support ？

断网，关机。可能的话，从另外一台电脑直接通过硬盘备份重要数据，而不是在被感染的电脑上操纵，免得让木马检测到后直接加密你数据

@Jirajine
谁告诉你浏览器是必须要一直升级的程序？

按你这说法，内核还是必须要升级的，服务器还是必须要升级的，或者说操作系统本身就是必须要升级的。所以用 LTS 的结果就是我必须要升级？？？

用 LTS 的目的就是不升级，同时还能接收必要的安全更新，这本是 security 源的作用，而不是为了最新的功能不停的升级。

至于 snap ，canonical 都没敢这么直白的说出专门给 Ubuntu 用，官方的说法都是为了提供跨平台的 Linux 包格式，你是怎么才能说出这话的？

@Jirajine
不是 LTS 的 ubuntu ，难道 apt 仓库里的 chromium 就不是 snap 的了？
https://packages.ubuntu.com/mantic/chromium-browser 2310 版本里的 chromium 一样是 snap 版的壳。

再退一步，用 LTS 的版本就是为了能够长时间不升级，怎么到你这里就成了用 LTS 反而就该用更新的版本了？

再再退一步，你想某个整体系统长时间不升级，但是某些特定包更新，那也应该给用户自己选择。同时在 apt 仓库里维护一个版本，snap 提供另外一个版本，交给用户自己选择想要哪个版本，而不是强制推 snap 版。

第一条算什么槽点，多半是你自己哪里没搞对。

debian 从某个版本开始（可能是 Buster ），bash 的非 root 用户的 PATH 里不再包含 sbin 的路径。如果此时你直接通过`su`切换为 root 用户的话，PATH 路径就不会包含 sbin ，但如果是`su -`切换的话，PATH 就会包含 sbin 。

你在其他发行版上直接`su`过去能够找到多半是因为其他发行版默认加入了 sbin 到非 root 用户的 PATH 里。

snap 最让我反感的是 canonical 为了强推这玩意儿把 apt 仓库里的包换成了 snap 的。

说起来 canonical 的推的几乎全都被其他取代了 upstart vs systemd 、mir vs wayland 、unity vs gnome 、snap vs flatpak 。

@kidlj 让系统 bug 和后门不复存在不可能。能大量减少也许还有可能。
写一个程序，来判断另外一个程序有没有 bug ，这类问题最终是个停机问题，是不可解的。

AI 能做到的无非是和现在杀软的工作类似，能有多少的准确率预测出是否有 bug 。
而且对于一个 AI 算法来说，存在对抗样本，肯定会有人发明出能欺骗 AI 的后门代码的。

@yankebupt #37

各大发行版的官方包维护者已经是类似的机制了。要成为官方的包维护者，必须要得到一个甚至多个 sponsor 的支持才能让你加入。

然而这套方案在开发者身上显然不适用，开发者并没有必要非要让某个软件加入到你信任关系里。更直白一点就是，我写的代码你爱用不用，我又没求你用干嘛还要申请入伙。

这次的问题是，各大发行版的包维护者都无条件地信任了上游的代码，导致带后门的包进入了官方仓库，还好在进入 stable 之前被人发现了，从而限制了影响范围。

真要说解决这类问题的方案，估计也就只能增加包维护者的责任了。但实际上，很多包维护者和开源软件作者一样，本来就是志愿工作。以前成为了某个包的维护者，但是现在没太多精力 review 代码，导致后门悄悄溜进了下游。