在原版本上使用安全更新（Backporting）

在原版本上使用安全更新是一种将重要的安全更新应用到软件中的方法。

我们把从upstream软件包的最新版本中获取的安全漏洞的修复方法应用到我们发布的原版本的软件包上的方法称之为backporting。

对于像红帽这样的厂商来说，backporting是很常见的，并且它可以保证以尽可能小的风险来为客户系统部署已有的更新。Backporting对于那些更熟悉专有软件更新的人来说是一个新概念。

这是我们为什么要在原版本上修复安全漏洞的一个例子。

红帽Linux 8.0发布版本中包含Apache HTTP 2.0.40版本。在发布后不久， Apache软件基金会发现了几个安全问题，并发布了一个新版本2.0.43，包含了这几个问题的修复版本。但是，除了安全方面的更新外，在2.0.40和2.0.43之间还进行了很多修改（包括功能增强和bug修复）。

这里面有一个功能修改了模块接口。在这种情况下，如果红帽发布一个Apache HTTP 2.0.43版本的安全更新，替代原来的版本2.0.40，那么用户之前所使用的所有的模块都需要更新（重新编译）以便与新的模块接口匹配。如果用户还使用了一些第三方的模块，那么他们必须向第三方厂商求助以获取更新。而且，Apache HTTP从2.0.40版本升级到2.0.43版本需要系统管理员的手动操作，这对于像红帽网络这样的自动升级系统来说也是不合适的。

像这样的问题，我们就可以在原版本上进行修复，当我们在原版本上进行安全更新时，需要

• 找到修复内容，并将其与其他更改剥离开来。
• 确定该修复不会引入其他的副作用
• 将该修复应用到之前发布的版本中

对多数产品来说，我们的默认策略是在原版本中只引入安全更新，但有时，在经过缜密的分析和测试后，我们也会在原版本中提供一些包的版本更新。这些包一般是跟其他包没什么关系，或者是最终用户使用的包，比如像网页浏览器和即时通讯客户端。

理解发布版本号

在原版本上部署安全更新对用户来说有很多优势，但同时也会产生一些不容易理解的地方。需要明白的一点是，从包的版本号上无法判断该包是否有漏洞。比如说，在很多地方您能看到这样的字眼“升级httpd到2.0.43修复该问题”，这里仅仅包含了一个版本号的信息。这就容易引起混淆，因为即使安装了厂商提供的更新包，用户看到的也不是最新的upstream版本，而是一个包含该补丁的原版本。

而且，有一些安全扫描和审计的工具也仅仅根据它们发现的软件包的版本信息来确定是否有安全漏洞。这也会导致一些错误的提示，因为这些工具并没有考虑在原版本上的安全更新。

随着红帽企业版Linux的引入，我们在考虑是通过升级到新的upstream版本来解决这样的问题还是在已有的版本上修复该问题上非常谨慎。从2000年1月开始，我们在所有的说明文档上都增加了CVE名字，这样用户就很容易地前后参照漏洞并找到我们什么时候修复该漏洞，如何修复该漏洞的，这些都与版本信息无关。

我们也提供了 OVAL 定义（说明文档的机读版本），这样一些第三方的漏洞检测工具可以用来查看漏洞状态，包括我们在原版本上应用这些更新的情况。这样做的目的就是希望消除大家对在原版本上引入安全更新的问题的疑惑，让用户能够更容易地保证系统的安全性。