Bug 108652

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:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108205
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108454
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108498



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

How reproducible:
Always

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
dependencies.


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.