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):
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
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 ***