Bug 174630 - rpm -e --repackage produces RPMs with bad digest
rpm -e --repackage produces RPMs with bad digest
Status: CLOSED DUPLICATE of bug 108083
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-30 16:35 EST by Josh Kelley
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 14:54:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Kelley 2005-11-30 16:35:19 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?
Comment 1 James Olin Oden 2005-11-30 16:57:16 EST
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).
Comment 2 Josh Kelley 2005-11-30 17:10:35 EST
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.
Comment 3 Paul Nasrat 2005-12-01 14:54:59 EST

*** This bug has been marked as a duplicate of 108083 ***

Note You need to log in before you can comment on or make changes to this bug.