Bug 108652

Summary: up2date does not perform enough sanity checking on downloads
Product: [Fedora] Fedora Reporter: Paul W. Frields <stickster>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED CANTFIX QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: high    
Version: rawhideCC: davids, gczarcinski, gfreeman, redhat-bugzilla, robatino
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: noarch   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-29 13:47:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 120092    

Description Paul W. Frields 2003-10-30 21:57:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027

Description of problem:
When up2date downloads updated packages, it does not perform enough sanity
checks to ensure that the downloaded .rpm file is a complete package (according
to at least a digest check via MD5 or SHA1). This has resulted in a number of
different bugzilla entries, none of which correctly diagnose the actual problem
that should be fixed in up2date. The proximate cause on the server side appears
to be redirects or missing files, but up2date could take care of this problem
(or at least the user confusion) by providing better sanity checks.

See also bugzilla entries:

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

How reproducible:

Steps to Reproduce:
1. Attempt to up2date when server has bad redirection or missing file.
2. Up2date downloads 404 or other error page as target .rpm file.

Actual Results:  Up2date attempts to upgrade to erroneous .rpm with either a
long hang, public key trust error, or by leaving system in a sorry state, i.e.
previously installed packages are now missing, sometimes in defiance of

Expected Results:  Up2date should do the equivalent of "rpm -K <file>" (or "rpm
-K --nosignature <file>" depending on user's up2date configuration) to check all
packages before beginning to upgrade. Because the update happens as a bulk
package erase, followed by a bulk package install, an error midway through the
install portion can leave the user's system in an unhappy state.

Additional info:

The /usr/share/rhn/up2date_client/rpmUtils.py has some interesting stuff in the
checkRpmMd5 function, but not being a Python programmer, I haven't made too much
of an effort to suss it all out. Even if the function is doing good work here,
the overall workflow needs to be revisited to prevent these kind of problems,
since Fedora Core will be pointed at all sorts of yum repos by its numinous users.

I would call this a "high-priority" RFE worthy of an errata release when it's
addressed, simply because the possible fallout from an error can be so severe.

Comment 1 Tyler Larson 2004-01-15 16:54:35 UTC
Furthermore, once a file exists in /var/spool/up2date with the same
name of the file up2date wants to download, up2date assumes that the
existing file is complete and doesn't attemt to re-download it. And,
since the RedHat server is under heavy load, it frequently drops
connections mid-download, and the incomplete download exception is
either untriggered (very possible with HTTP) or ignored.

As a result, a VERY large number of users have corrupted or incomplete
RPM packages in their download directory that effectively block
up2date from operating. So for many users who don't know how to
manually clear their /var/spool/up2date, up2date is broken and
completely unusable.

up2date needs to verify package integrity not only before installing,
but also before downloading (or rather before not downloading packages
that already exist on the machine). Packages that fail verification
must be discarded and re-downloaded.

I would call this fix a "high-priority", but I'd put it on the same
level of importance as patches for exploitable security holes, as the
existing versions of up2date are blocking many common users from
installing any updates at all, including security patches. Since this
problem gets more widespread with time, an errata release fixing this
problem should be issued as soon as possible.

Comment 2 Adrian Likins 2004-01-20 19:31:45 UTC
working on robustifying the yum/apt repo backends atm...
no eta promised...

Comment 3 Jeremy Katz 2004-05-12 20:43:33 UTC
*** Bug 122571 has been marked as a duplicate of this bug. ***

Comment 4 John Thacker 2006-04-22 15:15:34 UTC
*** Bug 135333 has been marked as a duplicate of this bug. ***

Comment 5 John Thacker 2006-10-29 13:47:11 UTC
Note that FC2 is no longer supported even by Fedora Legacy.  Also, up2date has
been replaced by pirut and pup since FC5.  FC3 and FC4 are supported by Fedora
Legacy for security issues only.  If this still occurs on FC3 or FC4 and is a
security issue, please reopen and assign to that version and Fedora Legacy.  If
it occurs on RHEL 3 or 4, please reassign or refile against that product.

The codebase for pirut and pup is quite different, so existing bugs do not
apply, but please continue testing them on the still supported versions of
Fedora Core and file bugs as necessary.