Bug 174630 - rpm -e --repackage produces RPMs with bad digest
Summary: rpm -e --repackage produces RPMs with bad digest
Keywords:
Status: CLOSED DUPLICATE of bug 108083
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-30 21:35 UTC by Josh Kelley
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-12-01 19:54:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Josh Kelley 2005-11-30 21:35:19 UTC
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 21:57:16 UTC
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 22:10:35 UTC
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 19:54:59 UTC

*** 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.