Bug 520328

Description of problem:

The "--security" option, which is provided by the yum-plugin-security RPM in the yum-utils source RPM, aims to limit updates to security related changes.  Unfortunately "yum --security update" fails to find all security updates.

The problem can best be seen by comparing the behaviour of "yum --security update" to PackageKit's Update Applet.  I believe PackageKit is working correctly and "yum --security update" is missing security updates.


Version-Release number of selected component (if applicable):

Fedora 11 x86_64
yum-3.2.23-3.fc11.noarch
yum-plugin-security-1.1.22-1.fc11.noarch


How reproducible:

The problem is always reproducible if there are security updates pending that "yum --security update" misses.  See "Additional Info" for a discussion of which updates are missed.


Steps to Reproduce:

1. Find a relative new system with a significant number of security updates pending.
2. Make a note of all security updates listed by PackageKit's Update Applet.  Clicking on the "Install" columns sorts such that all security updates are together.
3. Cancel out of the PackageKit's Update Applet.
4. Attempt to apply the security applets from the command line with
    yum --security update
  

Actual results:

Some security updates, particularly those that have a non-zero epoch for the existing installed package, are excluded.


Expected results:

"yum --security update" should install precisely the same packages as PackageKit's Update Applet.


Additional info:

I believe for both PackageKit's Update Applet and for "yum --security update" the desired behaviour is to apply all updates listed in /var/cache/yum/updates/updateinfo.xml.gz where the "update" is type "security" and where the version, including the epoch, is greater than the currently installed version.  PackageKit's Update Applet seems to do this correctly.

"yum --security update" seems to have a problem in update_md.py where "pkg['epoch']" in get_applicable_notices() should be populated with the epoch of the new package (the candidate being tested to see if it should be installed) but instead it is always "None".

The existing code assumes a value of zero when "pkg['epoch']" is "None", but this causes _rpm_tup_vercmp() to always conclude that the new package is too old when the epoch of the old package (the one currently installed) has a non-zero epoch.  "qt" is an example of a package with a non-zero epoch:
    > rpm -q --queryformat '%{NAME}-%{ARCH}-%{EPOCH}\n' qt
    qt-x86_64-1
    qt-i586-1

The attached patch assumes that the epoch of the new package is the same as the epoch of the old package instead of assuming it is zero.  Although not ideal this gets the behaviour of "yum --security update" closer to PackageKit's Update Applet.

There is additional work to be done in determining what needs to be done to get "pkg['epoch']" correctly populated.

I've set the severity of this bug to high since I think there is a risk of people being vulnerable who incorrectly think they have secured their systems with "yum --security update" and because I think the attached patch is an improvement.  So a quick fix is possible.