This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 117054 - up2date gets permanently crippled by .hdr download error
up2date gets permanently crippled by .hdr download error
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
3
All Linux
high Severity medium
: ---
: ---
Assigned To: Adrian Likins
: Security
: 121090 (view as bug list)
Depends On:
Blocks: FC2Blocker up2date-fc2 FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-02-27 14:47 EST by Alan Cox
Modified: 2007-11-30 17:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 02:34:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2004-02-27 14:47:13 EST
If up2date is interrupted or otherwise gets a corrupt ".hdr" file then
it gets permanent indigestion. Every further use of it blows up (with
diagnostics to console and no apparent info to the user - which is
also bad) when the gzip library fails to handle the .hdr file. 

It ought I imagine to at least catch the gzip error and purge the
relevant cache entry, and preferably then re-fetch it and retry. Just
purging it, giving a sane error and letting the user rerun it would help.
Comment 1 Alan Cox 2004-03-12 17:31:15 EST
Raised to security since it seems I can cause this simply by hijacking
DNS or being a hostile package supplier. If you think about the 'break
into mirror, install broken .hdr file and cripple every user of the
mirror' case its not pretty...
Comment 2 Warren Togami 2004-04-18 16:27:32 EDT
Uh oh... is Bug #121090 a case of this?
Comment 3 Terje Bless 2004-11-13 08:12:11 EST
Bug #121090 does look like a dup of this.

The easy fix is probably to catch the exception and notify the user
of the problem -- *including* the filename that caused it to barf! --
rather than trying to figure out a safe way to delete a file in
response to an exception, or to try to recover silently.

Granted I've not run into this since somewhere around FC2-ish, but
then tracking Rawhide tends to develop automated avoidance routines
like periodically purging the .hdr cache manually.
Comment 4 Alan Cox 2004-12-03 12:53:28 EST
Duplicated this with yum - still in FC3
Comment 5 Adrian Likins 2004-12-03 15:01:56 EST
need an example of a corrupt header, changes some
time in fc3 should eliminate getting stuck on gzip
errors with bogus headers (in up2date, no idea about yum)
Current versions should give an error about error loading
header and then automatically redownload it. RHEL4/FC3
should be do this. 

If you see otherwise, get me a copy of the traceback
and the bogus header (or if need be, a tar of all of
/var/spool/up2date). 
Comment 6 Rahul Sundaram 2005-09-05 02:25:58 EDT
*** Bug 121090 has been marked as a duplicate of this bug. ***

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