Bug 102986

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

Description of problem:
I don't know whether this bug is really in up2date, or if it's in gdm, or in
RPM, or something else altogether. up2date is my best guess for now.

When installing the new gdm errata package for Red Hat 9, sometimes up2date will
segfault after downloading the package. If rollbacks are enabled, the segfault
happens before the old version of gdm is repackaged.

The segfaults magically disappear when GPG checking is disabled in
/etc/sysconfig/rhn/up2date.

In the real world I've seen this only when installing the Red Hat 9 GDM errata
onto Red Hat 9 boxes. I haven't tried pushing Red Hat 7.x or 8 boxes to see if I
can make them fail like this, however. I also have not seen this happen with any
other packages.

Version-Release number of selected component (if applicable):
up2date-3.1.23.1-5 (maybe up2date-3.1.23-1 as well)

How reproducible:
Sometimes (although I will be attaching a shell script that makes the bug easy
if not trivial to reproduce)

Steps to Reproduce:
1. Install Red Hat 9 on machine. 
2. Register it with RHN (or a Current server).
3. (Optional?) Install all of the errata packages (except gdm).
4. (Optional?) Install RPM 4.2-1 from ftp.rpm.org.

Method 1:
5. Run "up2date gdm" as root.
6. If that failed to blow up, use "rpm -Uvh --oldpackage" to reinstall the old
gdm package, and repeat step 5.
7. If it still hasn't blown up, repeat step 6 several (up to 20?) more times.

Method 2:
5. Run the "explode2date" shell script which I will be attaching. (Keep a copy
of the gdm package, as shipped with Red Hat 9, in the current directory when you
run the script.)

Bonus Bug ;)
If you keep trying to run explode2date even after up2date's segfaulted once
already, rpm will get slower and slower. If you do this enough times, you may be
able to run "rpm -qa" and read all the package names in real time without using
a pager or scrollback, on a multi-GHz machine. At that point it may take up2date
half an hour per run, though, so you'll probably get sick of waiting for up2date
before you slow down rpm that much. Rebooting will restore things back to full
speed. AFAICT this effect, like the segfault, only happens when up2date's GPG
checking is enabled -- but I could be wrong. (I'll file a separate bug for this
if you want.)

Actual Results:  [root@crystal3 root]# ./explode2date

Fetching package list for channel: redhat-linux-i386-9...
########################################

Fetching Obsoletes list for channel: redhat-linux-i386-9...
########################################

Fetching rpm headers...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
gdm-2.4.1.3-5.1.i386.rpm:   ########################## Done.
./explode2date: line 10:  1511 Segmentation fault      up2date gdm
1
[root@crystal3 root]#

Expected Results:  up2date shouldn't segfault. The script should keep upgrading
and downgrading gdm until RHN or your hardware dies. (To see what the expected
results look like, disable GPG checking in /etc/sysconfig/rhn/up2date and try
running the script again.)

Additional info:

I get the strange feeling that it takes more attempts for the explode2date
script to fail against my RHN account (4-10 tries) than against my own Current
1.4.4 server (1-4 tries). This could very well be some other variable in my
testing, however.

I've set the bug's severity to "Security" because, well, it prevented a security
update from being automatically applied on some of my boxes. If that's an
overreaction, feel free to reduce the Severity to "High".