Bug 108652 - up2date does not perform enough sanity checking on downloads
up2date does not perform enough sanity checking on downloads
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
noarch Linux
high Severity medium
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
: FutureFeature
: 122571 135333 (view as bug list)
Depends On:
Blocks: 120092
  Show dependency treegraph
Reported: 2003-10-30 16:57 EST by Paul W. Frields
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-29 08:47:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul W. Frields 2003-10-30 16:57:44 EST
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 11:54:35 EST
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 14:31:45 EST
working on robustifying the yum/apt repo backends atm...
no eta promised...
Comment 3 Jeremy Katz 2004-05-12 16:43:33 EDT
*** Bug 122571 has been marked as a duplicate of this bug. ***
Comment 4 John Thacker 2006-04-22 11:15:34 EDT
*** Bug 135333 has been marked as a duplicate of this bug. ***
Comment 5 John Thacker 2006-10-29 08:47:11 EST
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.

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