Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 117054

Summary:	up2date gets permanently crippled by .hdr download error
Product:	[Fedora] Fedora	Reporter:	Alan Cox <alan>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	3	CC:	byte, djcovey, k.georgiou, link, mjc, nphilipp, sundaram, wtogami
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-09-05 06:34:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	114961, 120068, 123268, 136451

Description Alan Cox 2004-02-27 19:47:13 UTC

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 22:31:15 UTC

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 20:27:32 UTC

Uh oh... is Bug #121090 a case of this?

Comment 3 Terje Bless 2004-11-13 13:12:11 UTC

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 17:53:28 UTC

Duplicated this with yum - still in FC3

Comment 5 Adrian Likins 2004-12-03 20:01:56 UTC

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 06:25:58 UTC

*** Bug 121090 has been marked as a duplicate of this bug. ***