United States (change)
Shortcuts: Downloads Fedora Red Hat Network
The term 'backporting' is used to describe when we take a fix for a security flaw out of the most recent version of a software package, and apply that fix to an older version.
Backporting is common practice amongst software vendors such as Red Hat and is essential to ensuring that we can deploy automated updates on customers systems with minimal risk. However, backporting will be a new concept to those more familiar with proprietary software updates.
For an example of why we backport fixes let's look at Apache. Red Hat shipped the Apache web server version 2.0.40 with Red Hat Linux 8.0. Shortly after the release, a number of security issues were found and disclosed by the Apache Software Foundation. The Apache Software Foundation issued a new release, Apache 2.0.43, which contained fixes for those issues.
However, in addition to security fixes, a number of other changes had been made between Apache versions 2.0.40 and 2.0.43 including other bug fixes and the addition of new features. One of these features made a change to the module interface. Therefore if Red Hat was to issue a security update to Apache with version 2.0.43 replacing version 2.0.40, any modules that customers were using would have to be updated (recompiled) to match the new module interface. If any modules from third-party vendors were being used, customers would have to go back to the supplier of those modules to get updates. So moving from Apache 2.0.40 to 2.0.43 required manual effort by system administrators, and therefore would not be suitable for automated upgrade systems like Red Hat Network.
So in cases like this, Red Hat has another option, backporting: We identify the security fixes, isolate them from any other changes, make sure the fixes don't introduce any unwanted side effects, and apply them to our previous released versions.
Whilst on some products our default policy is to backport security fixes, we do from time to time provide version updates of some packages after careful testing and analysis. These are likely to be packages that have no interaction with others, or are used by an end-user (such as a web browser).
Backporting has a number of advantages to customers, but it can create confusion when it is not expected. Customers need to be aware that just looking at a version number of a package by itself doesn't help you know if you are vulnerable to a security issue. For example, stories in the press may include phrases such as "upgrade to Apache httpd 2.0.43 to fix the issue."
Some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find; even established tools will give you false positive for many vulnerabilities in Apache httpd, for example.
Since the introduction of Red Hat Enterprise Linux we have been careful to explain in our security advisories how we fixed an issue-- by moving to a new upstream version of the code or by applying patches to the existing versions. We've also attached CVE names to all our advisories since January 2000, which lets customers easily cross-reference a particular vulnerability and find out when and how we fixed it, independent of version numbers. We also supply OVAL definitions that are machine-parsable versions of our advisories that third-party vulnerability tools can use to determine the status of vulnerabilities even in backported fixes. In doing this, we hope to remove some of the confusion surrounding backporting, and make it easier for customers to always keep up to date with the latest security fixes.