Bug 76899 - rpm --import creates duplicate gpg-pubkey entries without checking
Summary: rpm --import creates duplicate gpg-pubkey entries without checking
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 8.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-28 23:56 UTC by Bert de Bruijn
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

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


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