Bug 76899 - rpm --import creates duplicate gpg-pubkey entries without checking
rpm --import creates duplicate gpg-pubkey entries without checking
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-28 18:56 EST by Bert de Bruijn
Modified: 2008-05-01 11:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-10-28 18:56:38 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 Bert de Bruijn 2002-10-28 18:56:32 EST
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 09:36:13 EST
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 12:12:37 EST
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 17:42:10 EST
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.