7 Backports of source code #
SUSE extensively uses backports, for example for the migration of current software fixes and features into released SUSE Linux Enterprise packages. The information in this chapter explains why it can be misleading to compare version numbers to judge the capabilities and the security of SUSE Linux Enterprise software packages. This chapter also explains how SUSE keeps the system software secure and current while maintaining compatibility for your application software on top of SUSE Linux Enterprise products. You will also learn how to check which public security issues actually are addressed in your SUSE Linux Enterprise system software, and the current status of your software.
7.1 Reasons for backporting #
Upstream developers are primarily concerned with advancing the software they develop. Often they combine fixing bugs with introducing new features which have not yet received extensive testing and which may introduce new bugs.
For distribution developers, it is important to distinguish between:
bugfixes with a limited potential for disrupting functionality; and
changes that may disrupt existing functionality.
Usually, distribution developers do not follow all upstream changes when a package has become part of a released distribution. Usually they stick instead with the upstream version that they initially released and create patches based on upstream changes to fix bugs. This practice is known as backporting.
Distribution developers generally will only introduce a newer version of software in two cases:
when the changes between their packages and the upstream versions have become so large that backporting is no longer feasible, or
for software that inherently ages badly, like anti-malware software.
SUSE uses backports extensively as we strike a good balance between several concerns for enterprise software. The most important of them are:
Having stable interfaces (APIs) that software vendors can rely on when building products for use on SUSE's enterprise products.
Ensuring that packages used in the release of SUSE's enterprise products are of the highest quality and have been thoroughly tested, both in themselves and as part of the whole enterprise product.
Maintaining the various certifications of SUSE's enterprise products by other vendors, like certifications for Oracle or SAP products.
Allowing SUSE's developers to focus on making the next product version, rather than spreading their focus thinly across a wide range of releases.
Keeping a clear view of what is in a particular enterprise release, so that our support can provide accurate and timely information about it.
7.2 Reasons against backports #
It is a general policy rule that no new upstream versions of a package are introduced into our enterprise products. This rule is not an absolute rule however. For certain types of packages, in particular anti-virus software, security concerns weigh heavier than the conservative approach that is preferable from the perspective of quality assurance. For packages in that class, occasionally newer versions are introduced into a released version of an enterprise product line.
Sometimes also for other types of packages the choice is made to introduce a new version rather than a backport. This is done when producing a backport is not economically feasible or when there is a very relevant technical reason to introduce the newer version.
7.3 The implications of backports for interpreting version numbers #
Because of the practice of backporting, one cannot simply compare version numbers to determine whether a SUSE package contains a fix for a particular issue or has had a particular feature added to it. With backporting, the upstream part of a SUSE package's version number merely indicates what upstream version the SUSE package is based on. It may contain bug fixes and features that are not in the corresponding upstream release, but that have been backported into the SUSE package.
One particular area where this limited value of version numbers when backporting is involved can cause problems is with security scanning tools. Some security vulnerability scanning tools (or particular tests in such tools) operate solely on version information. These tools and tests are therefore prone to generating “false positives” (when a piece of software is incorrectly identified as vulnerable) when backports are involved. When evaluating reports from security scanning tools, always check whether an entry is based on a version number or on an actual vulnerability test.
7.4 Checking for fixed bugs and backported features #
Information about backported bug fixes and features is stored in several locations:
The package's changelog:
>rpm -q --changelog name-of-installed-package>rpm -qp --changelogpackagefile.rpmpackagefile.rpmThe output briefly documents the change history of the package.
The package changelog may contain entries like
bsc#1234(“BugzillaSuse. Com”) that refer to bugs in SUSE's Bugzilla tracking system or links to other bugtracking systems. Because of confidentiality policies, not all such information may be accessible to you.A package may contain a
/usr/share/doc/PACKAGENAME /README.SUSEfile which contains general, high-level information specific to the SUSE package.The RPM source package contains the patches that were applied during the building of the regular binary RPMs as separate files that can be interpreted if you are familiar with reading source code. See 第 9.1.3.5 节 “安装或下载源软件包” for installing sources of SUSE Linux Enterprise software. See 第 9.2.5 节 “安装和编译源软件包” for building packages on SUSE Linux Enterprise. See the Maximum RPM book for details about software package builds for SUSE Linux Enterprise.
For security bug fixes, consult the SUSE security announcements. These often refer to bugs through standardized names like
CAN-2005-2495which are maintained by the Common Vulnerabilities and Exposures (CVE) project.