From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: After downloading some packages, I can --checksig them fine (they aren't GPG signed, but they do have an MD5 sum). Trying to install these particular packages failed with a cpio error on one of the files in one of the packages. After trying to install them, the packages no longer --checksig fine; one of the file's MD5 sums has changed. Version-Release number of selected component (if applicable): RPM version 4.0.4 How reproducible: Tried briefly, but couldn't. Steps to Reproduce: 1. Install a version of mozilla earlier than 1.1 using the RH 7.x RPMs found on ftp.mozilla.org. I'm not sure what steps are required to create the proper "crud" in /var/lib/mozilla* 2. 'rpm -e' all mozilla packages. 3. Download mozilla-1.1 from ftp.mozilla.org. Make a backup copy of the mozilla-1.1 package. 3. rpm --checksig all mozilla packages; they should work (they use only MD5 checksums). 4. Try to rpm -i all mozilla packages; the mozilla-1.1 package fails with a complaint about an invalid cpio checksum on one of the files in it. 5. rpm --checksig the mozilla packages again; the mozilla-1.1 package has changed, and the checksum will be invalid. 'diff'ing the backup copy and the current copy reveals that the file has changed. 'diff'ing the 'hexdump'ed files reveals that the change is not a few characters, but many. To get mozilla-1.1 to work properly: 6. rpm -e all mozilla packages. 7. rm -Rf /usr/lib/mozilla* 8. rpm -i all mozilla packages. They will work this time, and the checksum will still be valid. Actual Results: RPM modifies part of one of the package files upon failed install. Expected Results: RPM should never modify an RPM unless it is building one or adding a signature. When trying to install a package, RPM should open the file read-only, since the write permission is unnecessary. (right?) Additional info: System is installed with all 7.2 errata, as far as I know. I used mozilla-1.0 for a long time, then mozilla-1.1b, and now mozilla-1.1. Thus, when I encountered this error, I had a /usr/lib/mozilla, /usr/lib/mozilla-1.1b, and after the failed install I had a /usr/lib/mozilla-1.1. Removing all three let me install mozilla. I don't think this is a security issue because there are lots of mitigating factors (the user must be root and try to install the package in order to modify it). But it is annoying (after one failed attempt at installing the package, you need to reobtain the RPM to try to reinstall it). This could be an issue somehow with the mozilla packages itself, but it seems unlikely that the install script would modify the package.
What release of rpm-4.0.4 (i.e. rpm -q rpm)?
[root@paul mozilla]# rpm -q rpm rpm-4.0.4-7x
Try rpm-4.0.4-7x.18 from Red Hat 7.3, there are other important fixes there. Even better is rpm-4.1 from Raw Hide or ftp://ftp.rpm.org/pub/rpm/test-4.1 all but released. Meanwhile back to your problem. Did you reproduce this problem, or did it just happen once? Is NFS involved?
Created attachment 73844 [details] Transcripts of failures
I have reproduced it two more times, essentially by installing mozilla-1.1b, using it, removing it, installing mozilla-1.1, using it, removing it, and repeating. I have not been able to make it fail consistently (unfortunately). NFS is not involved... I don't have any NFS mounts or exports. I've attached the transcripts of these two latest failures. I also have copies of the RPM file before and after having one of these failures, if you'd like to look at what parts of the files are getting changed.
OK, I believe you're seeing a problem, thanks for making the effort to reproduce. Can you also attach the output of "rpm -qa"? Problems like you are reporting are often with other packages. In fact, I'm hard pressed to understand how rpm (which opens packages for install with O_RDONLY, verify with strace if you wish) can modify the original package contents at all. Off to mozilla for a 2nd opinion. glibc mmap'ed stdio? kernel? hardware?
7.3 doesnt have mmap stdio not that it should matter I'd like to know what the results are if you have time to do chmod 400 on the package that seems to get modified then run rpm strace -o logfile rpm ... Then gzip the logfile and attach it
Sorry... bad hardware seems to be most suspect. (IBM DeskStar hard drive which died soon after I reported the bug, and also memtest86 found some errors in the RAM.) Thanks, though; your support is great! :)