Red Hat Bugzilla – Bug 174630
rpm -e --repackage produces RPMs with bad digest
Last modified: 2007-11-30 17:11:18 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: I tried to create a package using rpm -e --repackage, but the resulting RPM did not pass rpm --verify. Version-Release number of selected component (if applicable): rpm-4.4.1-22 How reproducible: Always Steps to Reproduce: 1. Install Opera, using the Fedora Core 4 RPM from their web site. 2. Install meld, from Dries' repository. 3. rpm -e --repackage opera 4. rpm -e --repackage meld 5. rpm --checksig /var/spool/repackage/opera* 6. rpm --checksig /var/spool/repackage/meld* Actual Results: opera-8.51-20051114.6.i386.rpm: MD5 NOT OK meld-1.0.0-1.2.fc4.rf.noarch.rpm: (sha1) dsa sha1 MD5 GPG NOT OK Expected Results: opera-8.51-20051114.6.i386.rpm: md5 OK Additional info: I was surprised that rpm --checksig reported that meld's DSA and SHA1 signatures were okay. That's possible without access to the signing key?
This is actually by design. The header is poisened by the addition of the REMOVETID (and removal of the INSTALLTID) tag. The original thinking was that these repackaged packages were not to be used like regular packages, because though they have the same NEVRA, they are not always identical to the original package (this to is by design). Repackage was really meant to be used in the context of providing the bread crumbs to allow the transactional rollback feature to work (i.e. the --rollback option, and in the present in rpm 4.4.3 the autorollback feature). In that context the poisened signatures are understood to be there and work just fine (sort of).
I see. Thanks for the explanation. I guess, in that case, this bug might be considered a duplicate of #108083, since I'd think this kind of explanation ought to go in the description of the --repackage option on the manpage.
*** This bug has been marked as a duplicate of 108083 ***