Linux 发行版的补丁更新速度？

MFC

2017-03-04 14:55:16 +08:00

关键看社区的活跃度了，所以，你如果想要最及时的更新，还要是选择那些用户群大，开发者众多的发行版。。。

ivmm

2017-03-04 15:01:24 +08:00

RedHat 一般都能第一时间更新， CentOS 真的炒鸡慢，记得上次脏牛等了三星期还是两星期来着，直接全线换 Debian

Debian 因为内核维护者人多还积极，所以也能第一时间更新。

Ubuntu 不知道是因为 Debian 更新了的缘故还是自己也给力的缘故，反正也能第一时间更新

loading

2017-03-04 15:04:26 +08:00

查查那次 heartbleed 就知道了。

wevsty

2017-03-04 15:38:35 +08:00

好像更新最快的是 Arch
但是 Ubuntu 这种大众化选择可能更适合一般使用。
所以总结起来， Ubuntu 大法好

kokutou

2017-03-04 17:46:37 +08:00

Ubuntu 大法好

yylzcom

2017-03-04 17:51:00 +08:00

從資安事件的處理可以推敲出各作業系統商對於緊急事件的反應速度。時間軸，按照修復的先後排列：

OpenSSL (資安弱點的主角) 第一次公開揭露的時間約在 2014 年 4 月 6 日 0 時。
RedHat 在 2014 年 4 月 7 日 07:47:00 正式修復。
OpenSSL 正式確認並修復的時間約在 2014 年 4 月 7 日 16 時。
OpenBSD 約在 2014 年 4 月 7 日 20:17 正式修復。
Arch Linux 約在 2014 年 4 月 7 日 20:36 正式修復。
Debian 約在 2014 年 4 月 7 日 21:45 正式修復。
FreeBSD 約在 2014 年 4 月 7 日 21:46 正式修復。
Ubuntu 約在 2014 年 4 月 7 日 21:48 正式修復。 (2014 年 4 月 8 日分隔區)
Fedora 約在 2014 年 4 月 8 日 00:33 正式修復。
CentOS 約在 2014 年 4 月 8 日 02:49 正式修復。
OpenSUSE 約在 2014 年 4 月 8 日 05:32 正式修復。
Scentific 約在 2014 年 4 月 8 日 08:27 正式修復。
Gentoo 約在 2014 年 4 月 8 日 09:36 正式修復。

重點整理：
1. RedHat 修復的速度比 OpenSSL 官方還快。
2. RedHat 派系的修復時間，除了 RedHat 外都算慢，如 Fedora 及 CentOS 、 Scentific ，他們都比 RedHat 慢 16 小時以上。
3. Debian 派系的修復時間，如 Debian 及 Ubuntu ，都比 RedHat 慢上至少 12 小時以上。
4. Gentoo 是列表中修復最慢的。
5. 若以資安黃金 6 小時來說， Fedora 、 CentOS 、 OpenSUSE 、 Scentific 及 Gentoo 都不及格。

http://devco.re/blog/2014/04/11/openssl-heartbleed-how-to-hack-how-to-protect/

lydasia

2017-03-04 22:45:33 +08:00

@yylzcom 看来我选择 FreeBSD + Ubuntu 是对的。。

marguerite

2017-03-10 13:27:51 +08:00

实名反对高票答案。但反对也没有用，因为我猜那是摘抄。还有我不是来给 openSUSE 洗地的。

安全问题是有静默期的。发现问题到上游收悉是第一阶段，上游收悉到上游修复是第二阶段，上游修复到通知所有主流发行版是第三阶段（前提发行版有安全团队，比如 Mint 和一些主打美观的发行版根本就没有这样的 team ，自己开发的桌面环境都没有安全审计），主流发行版发布更新和问题披露是第四阶段。

我们能看到的安全问题应该从披露那个时点开始。所谓发行版补丁速度应该是指第四阶段披露和更新这两个并行作业的时间差（如果你在短跑，你应该不会回头看别人）。

具体怎么研究我也不会，因为是事中不透明的。事后看发行版的 bug 创建时间是没用的，因为 Redhat 的创建时间比 Debian 整整早了 20 个小时。但考虑到创建时 bug 是不公开的，所有发行版的 bug report 也都是不公开的，我觉得这个时间点不能代表响应速度（因为可能有机器人）。

另外那个 4 月 6 日 0 时肯定是发现时间，只不过后来页面公开了，被误以为是披露时间。按照安全问题的标准流程，不可能不给下游留修复时间就披露，下游比披露时间普遍晚一天是不可能的。

看软件包发布时间也是没用的，因为 RPM 系一般都是企业版支撑，有 QA 的，甚至还需要测试整合度（防止安全问题修好了，生产环境却挂了）。 Fedora 我不是很熟悉，只拿 openSUSE 说，正确的比较是 openSUSE 的 submit request 创建时间跟 Debian bugzilla 上面的 release 时间比，这样才能剔除 QA/autoQA 的作用。至于要不要 QA ，至少大公司认为是要的。至少我觉得 RPM 系比 Deb 系全面落后不可能是因为领工资不干活的原因。

PS ：有人说 openSUSE 的安全补丁比 SLE 慢，确实慢。我参与过的几十个安全更新里面， Leap 跟 SLE 是同时修复（一个企业版的维护者管两个包）， Leap 因为有些包跟 SLE 不一样，所以单独再跑一遍整合度测试。另外 openSUSE bugzilla 上面那个机器人不是实时的，我经常遇到我修好了一个 bug ，机器人两天之后才去更新页面，具体原理因为不是我写的，所以我不能说可能考虑了镜像同步检测这种话，也许就是 cron job 定时跑有阻塞呢。

另外还要考虑修复的有效性。 Debian 的 bugzilla 上 4 月 9 日还有人说修复好像没啥用，或者刷不出更新的问题。

再说一下 RHEL ，我看到楼上说的那个修复时间就感觉不正常，主要怀疑一是 RH 的关系铁，维护者私下收邮件了，或者就是他们发现的；二是老版本根本没受影响 bug 关得快。但看到 4 月 8 日 RH 的 errata 刚出来我就放心了。关于 RH 的时间全部弄错了。所以对 Fedora 的指责也是无端的，至少根据 bug report ， Fedora 的 QA 确认时间比 RH 6 要早，那请问这十几个小时他们是睡大觉去了嘛。

再来说 Debian 和 Ubuntu ，前后就差三分钟，是无脑 forward 的吧？据我所知 Debian 和 Ubuntu 不是所有底层包都完全相同的， Debian 能用 Ubuntu 可以用，但不一定系统不挂，三分钟能做完这一切？ excuse me ？这种无脑 forward 的问题存在于全部 deb 链条， Debian 到 Ubuntu ， Ubuntu 到一水儿的基于 Ubuntu 的发行版，似乎都刻意忽略了自己实际上改过底层这件事。按照原理讲，基于某某应该意味着你比某某要慢几个小时，因为你有你的测试要做。实际看好像这里的问题所有人都选择不去细想。

基于这些，我觉得高票答案的结论没有一条是准确的，正确答案应该是绝大多数主流发行版都是在 4 月 8 日这天搞定这个问题的（参考 Arch Linux 的时间，应该是没有 QA 的发行版里面比较客观的平均时间，因为它不需要制作包，所以可视为发布即到达）。所有发行版都是在 7 号晚九点左右知悉（因为上游是统一通知），第二天早 8 点左右开始陆续修复，最快跟最慢前后不会超过 6 个小时，这里包含 QA 时间，也就是说发布一个更新，不同发行版有工序上的差别，单单一个快字根本不足以说明问题，至少我认为 centos 的 fix 应该是相当 solid 的不会出现辗转反复一修二修三修这种情况。

最后这只是一个独例的分析，不足以得出普遍性结论的。

关于安全问题，我的建议是除非你自己就是安全专家，非常熟悉这个行业，否则请相信你发行版的专业性。不然就会出现外行看内行，得到南辕北辙的结论的情况。

marguerite

2017-03-10 14:09:23 +08:00

再来回答楼主的问题。

不同发行版差几十天的也有，比如社区发行版，维护者度假去了。

openSUSE 还有 SUSE 修了我不修的情况，因为我不认为受影响。比如 marked.js 问题，它是包含在 nodejs 里面用于编译时候创建 html 的，编译后的包里根本没有它。那它的代码的安全问题就不需要修复。这时候比如十几天后我闲得发慌就顺手补上这个谁也不会影响的安全漏洞，就会出现你说的那个情况。或者说我请求提交了，跟我对接的维护者没有实时做同行评审，这个在主流发行版也不全有，可以看成往自己 GitHub 灌 commit 跟提交 pull request 的区别。

流程上 Debian 应该比 RH 快，因为 RH 是企业版，强制 QA 。 Debian 不需要受这个限制。但现实中往往是企业版快，因为都有安全团队，一般都是修了自己再往上游交漏洞，正规军和游击队的区别。如果是外部发现，理论应该是 Debian 快，但绝大部分安全问题都是业内专家自己发现的，外部发现很少有告诉你的。

关于安全问题，我认为的第一梯队是 Debian 和企业版，第二梯队是基于企业版的发行版（因为有安全团队和 QA 双重保证），和独立包管理架构但人数很多的发行版比如 arch （应该提到第一梯队，但因为这类发行版的人数足以支撑运作独立的安全团队，却不足以让他们全职工作），第三梯队是基于第一，第二梯队的发行版，因为即使有 QA 和安全团队也还是天然的慢，不慢绝对是因为变相弯道超车，但可能把轮子跑丢，第四梯队是基于 Ubuntu 的发行版，和十分小众养不起安全团队的发行版，他们要么生死由命，要么只能在问题披露后才开始着手修复。 BSD 系列不了解不置喙

okudayukiko0

2017-03-10 22:15:59 +08:00

@marguerite 这个怎么解释呢，同样 MySQL 漏洞， openSUSE 比 SUSE 慢了十几天
https://www.suse.com/zh-cn/security/cve/CVE-2016-6662

marguerite

2017-03-12 14:05:17 +08:00

@okudayukiko0

我不是给 openSUSE 洗地的啊，慢就慢呗 :doge:

看了下那个 issue ，你也是会挑...那个 issue MySQL 自己都是偷偷补上的...SUSE 也是在一个大补丁集里补的， openSUSE 单独发了一个更新（这么看似乎还不错？）

另外比较企业版跟社区版也没意义啊… SLE 收费的。因为你已经是确定不想花钱了，那沉没成本就应该选择接受。

正确的解决你那个疑问的方式是，足够多的样本量（ 100 个重大安全事件？），社区版跟社区版比，看你日常使用的那个镜像的 update 通道里面那个更新的创建时间。 leaf （比如没人用的包）和组织结构（行政方式和松散管理）作为沉没成本抛开。

第一， openSUSE 的 mysql “可能”是个社区包， bug report 肯定会及时发，能不能及时更新是维护者的事情。 PS ：安全团队不是修安全问题，是发现通知审计安全问题。这对所有发行版都适用，包括 Debian ，你仔细找肯定会有别的发行版修了， Debian 落后几十小时的情况。人有三急，这都是半公开的秘密了。

第二，不是社区包，这十几个小时想想也正常，企业版维护者提交更新请求， review 和通过请求那人没起床呢。我不相信这种情况别人没有，至少看看 Fedora 也一样。那 Debian 肯定也跑不了。

至少我没见过：安全更新可以直接发布（因为那样所有的修复都会以安全更新的名义发出去），或者更新可以直接发布（看起来 Debian 似乎是这样？因为那样，质量无法保证。仅举一例：所有的问题都能通过更新解决，但发行版的更新策略决定了不是所有问题的修复都能够使用更新通道。所以至少要有同行评议或者一个主抓的人。如果 Debian 选择无脑相信，那就是它管理模式的弱点），或者安全团队直接更新有问题的软件（这会造成所有人都不 care 安全问题）。

所以你说的其实还是发行版的共性问题。

marguerite

2017-03-12 14:07:52 +08:00

楼主还不如关心关心镜像，就算 Debian 比 Fedora 早 5 小时，镜像是每六小时同时 rsync 取包，那有什么用……