Bug 520328 - "yum --security update" excludes packages with a non-zero epoch
Summary: "yum --security update" excludes packages with a non-zero epoch
Status: CLOSED DUPLICATE of bug 519405
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL: http://selliott.org
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-30 18:06 UTC by Steven Elliott
Modified: 2014-01-21 23:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-31 13:41:39 UTC

Attachments (Terms of Use)
A simple fix that assumse that the epoch has not changed (1.05 KB, patch)
2009-08-30 18:09 UTC, Steven Elliott
no flags Details | Diff

Description Steven Elliott 2009-08-30 18:06:57 UTC
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

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

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.

Comment 1 Steven Elliott 2009-08-30 18:09:13 UTC
Created attachment 359200 [details]
A simple fix that assumse that the epoch has not changed

Comment 2 seth vidal 2009-08-31 13:41:39 UTC

*** This bug has been marked as a duplicate of bug 519405 ***

Note You need to log in before you can comment on or make changes to this bug.