Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 76899

Summary: rpm --import creates duplicate gpg-pubkey entries without checking
Product: [Retired] Red Hat Linux Reporter: Bert de Bruijn <bob>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: milan.kerslager, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-28 23:56:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bert de Bruijn 2002-10-28 23:56:32 UTC
Description of Problem: rpm --import the same key twice. The rpm db will have
two entries for the same key. You can only delete them by rpm -e --allmatches,
and re-import the same key again.


Version of selected component (if applicable): rpm-4.1-1.06


How Reproducible: every time


Steps to Reproduce:
1. # rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
2. # rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
3. # rpm -q gpg-pubkey
4. # rpm -e gpg-pubkey
5. # rpm -e gpg-pubkey --allmatches


Actual Results:
rpm --import succeeds the second time
rpm -e gpg-pubkey fails because of multiple matches



Expected Results:
rpm --import should fail (gracefully or silently) the second time.

Comment 1 Jeff Johnson 2002-11-01 14:36:13 UTC
Erase multiple entries with --allmatches, reimport
a single instance.

The real problem is distributing public keys
with packages, not fixing --import behavior.

Comment 2 Bert de Bruijn 2002-11-04 17:12:37 UTC
Jeff,
I don't understand what you mean by "the real problem is distributing public
keys with packages" ? 
The /usr/share/doc/rpm-4.1/RPM-GPG-KEY was only an example, I also have public
keys that I got from the webpages of authors and packagers. Previous versions of
rpm used the users gnupg keyring, so one could get keys from keyservers, but now
that rpm has its own internal "keyring", you can only import keys from files.

Anyway, I understand the WONTFIX, the -e -allmatches + re-import works (as I
said in the original report). 
Using the package version as a counter would mean you could delete individual
copies, but that's not an elegant solution. Making rpm refuse to --import keys
that are already in the db would be cleaner IMHO.

Comment 3 Milan Kerslager 2003-01-10 22:42:10 UTC
The old behavior was better IMHO in some cases. At least you had only one place
with keyrings in the system. Current implementation is better when trying to
verify package on broken/compromited system. I underestand if this is the case.
rpmbuild still uses external gpg...

The better way could be an option to force use external program. The old
handling worked fine so why to drop it completly.

In the school the teacher told me that Unix uses external simple programs and
big programs with cumulated functions are not good (like sendmail)...