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.
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.
working on robustifying the yum/apt repo backends atm... no eta promised...
*** Bug 122571 has been marked as a duplicate of this bug. ***
*** Bug 135333 has been marked as a duplicate of this bug. ***
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.