Bug 90952 - rpm --import of a keyfile with signatures results in bad gpg-pubkey database entry
rpm --import of a keyfile with signatures results in bad gpg-pubkey database ...
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
: 68291 131859 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-05-15 14:43 EDT by Michael Schwendt
Modified: 2007-11-30 17:10 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-12 08:49:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rpmio/tring ../pubkey.54a2acf1 (8.82 KB, text/plain)
2003-05-22 05:01 EDT, Jeff Johnson
no flags Details
rpmio/tring togami.key (8.83 KB, text/plain)
2003-05-22 05:03 EDT, Jeff Johnson
no flags Details
rpm --import'ing this goes wrong (2.40 KB, text/plain)
2003-08-12 17:56 EDT, Samuli Kärkkäinen
no flags Details
shell script to strip ascii armored keys (1.01 KB, text/plain)
2004-04-07 11:49 EDT, Michael Schwendt
no flags Details

  None (edit)
Description Michael Schwendt 2003-05-15 14:43:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Certain GPG public keys are not imported correctly by RPM. The resulting RPM
database entries contain an incorrect version tag.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. gpg --recv-keys 54A2ACF1
2. gpg --export -a 54A2ACF1 > key.txt
3. rpm --import key.txt
4. rpm -q gpg-pubkey --last | head -1

Why does it get named 55f3aa6f?

  # rpm -qi gpg-pubkey-55f3aa6f | gpg 
  pub  1024D/54A2ACF1 --snip--
  sub  2048g/4AD75982 2002-11-25  [expires: 2007-11-24]

Actual Results:  gpg-pubkey-55f3aa6f-3e30940d                  Thu 15 May 2003
20:40:10 CEST

ASCII-armored key was parsed incorrectly, resulting in wrong key id.

Expected Results:  gpg-pubkey-54a2acf1-3e30940d                  Thu 15 May 2003
20:40:10 CEST

Additional info:

Comment 1 Pascal Volk 2003-05-15 15:45:40 EDT
Michael is using RHL 9.

I'm still using RHL 8.0 and rpm 4.1. Informations are available in Michaels
additional info number 3.
Comment 2 Jeff Johnson 2003-05-21 20:31:29 EDT
Yup, rpm has problems with multiple public keys in the same
OpenPGP packet.

I believe that Warren Togami has identified an inadvertent
2nd public key in his published public key. If someone
could attach a pointer to the other public key (I can't tell
which fingerprint is the correct one), I'll verify that as well.
Comment 3 Michael Schwendt 2003-05-22 02:36:50 EDT

or "keyserver wwwkeys.eu.pgp.net" and "gpg --recv-keys 54a2acf1".

Oh btw, when I import it into RPM, the gpg-pubkey-55f3aa6f id matches the key
fingerprint from Thomas Vander Stichele who is listed at the pgp.mit.edu site as
having signed Warrens key. Though when I run gpg on the ASCII-armored data, I
don't get any signatures displayed.
Comment 4 Jeff Johnson 2003-05-22 05:01:25 EDT
Created attachment 91884 [details]
rpmio/tring ../pubkey.54a2acf1
Comment 5 Jeff Johnson 2003-05-22 05:01:54 EDT
Thanks for pointer. Attached is the output of rpmio/tring
for the pubkey 0x54a2acf1.
Comment 6 Jeff Johnson 2003-05-22 05:03:21 EDT
Created attachment 91885 [details]
rpmio/tring togami.key
Comment 7 Michael Stefaniuc 2003-05-29 16:31:03 EDT
I'm bitten by the same problem with the fedora.us keys. Here is what i found out
how to workaround the problem:
rpm wrongly imports the key as gpg-pubkey-$version, where $version is always the
keyid of the first "sig 3" (as shown with the "gpg --list-sigs") signature. As
workaround i've imported the keys into gpg and with gpg --edit-key and then
delsig i've removed all "sig 3" signatures, excepting the self-signature.
Exporting the modified key and importing it into rpm gives the desired result.
Comment 8 Samuli Kärkkäinen 2003-08-12 17:54:51 EDT
I'm hitting this bug when rpm --import'ing key 8DF56D05, which I'll include as
an attachment. Every time I do the import, I get a new copy of package
gpg-pubkey-54a2acf1-3e828ae5 into the rpm database. 54A2ACF1 is the first "sig
3" signature of the key. I'm using rpm-4.2-0.69.
Comment 9 Samuli Kärkkäinen 2003-08-12 17:56:51 EDT
Created attachment 93610 [details]
rpm --import'ing this goes wrong
Comment 10 Anders Kaseorg 2003-10-27 22:04:50 EST
I have a similar problem importing my key, DFD3D769: I get a package named
gpg-pubkey-00000000-3a4801c4, and my signed RPMs don't verify. I'll attach the
key if you want. (Using rpm-4.2.1-0.30 and gnupg-1.2.2-3 on Fedora 0.95.)
Comment 11 Aleksey Nogin 2004-03-08 04:01:18 EST
*** Bug 68291 has been marked as a duplicate of this bug. ***
Comment 12 Per Nystrom 2004-04-04 16:14:14 EDT
Yep, this still exists even in Fedora Core 2 test 2.  At the very
least, can we have rpm issue a warning/error when trying to import a
key that has more than just its self-sig?  (Ideally, rpm would
silently strip the other sigs that would otherwise bork it, but I'll
take what I can get!)
Comment 13 Warren Togami 2004-04-04 22:38:59 EDT
Can anyone suggest a script or source code that takes a key and strips
it to be importable?
Comment 14 Jeff Johnson 2004-04-07 09:34:58 EDT
No way can this be done for fc2, you're way past my rpm devel
Comment 15 Michael Stefaniuc 2004-04-07 09:49:16 EDT
Why did you close this bug? The problem still exists and it exists
since rpm started to import gpg keys, afaik that would be RHL8.0 or
RHL9. So it's not a fc2 request and the bug is also in RHEL 3.
Comment 16 Jeff Johnson 2004-04-07 10:05:37 EDT
No one is saying the problem does not exist.

The bug was resolved to DEFDERRED for the reasons stated.
Comment 17 Michael Stefaniuc 2004-04-07 10:09:58 EDT
Why not "DEFERRED" and "OPEN"? If it's CLOSED no way that this will
ever be fixed because who will ever look at closed bugs.
Comment 18 Michael Schwendt 2004-04-07 11:49:11 EDT
Created attachment 99194 [details]
shell script to strip ascii armored keys

(Inspired by and based on signtool from Ronald Schmidt.)

What else would need to be stripped? Multiple uids? Self-signatures?
Comment 19 R P Herrold 2004-04-07 12:09:24 EDT
as to comment 15, I look at Closed and Deferred bugs as release
development progresses to make sure I update bugs when it is
appropriate in the development cycle; I have these stored queries,
just to do that (in part)

 Preset Queries  My Bugs  | DeferredRuss | distribution - all -
chan... | distribution - open | EveryRuss | OpenRuss |
OpenRussSubmitOnly | rpm all | rpm pending | Russ - all RFE |
RussFollowAll | RussFollowing | RussRawhideAll | RussRawhideClosed |
RussRawhideOpen | Whiteboard non NULL withi... 

Comment 20 Paul Nasrat 2004-04-07 12:12:58 EDT
With regards to script from comment 18

At the moment rpm --import calls through to rpmk via rpmpopt, only
major gotcha is rpm --import takes urls not files so we can't just
popt alias through the signature stripping script.

However this may provide the seed for a "workaround" until time can be
allocated for rpmlib work.  Jeff - opinions?
Comment 21 Jeff Johnson 2004-04-08 19:49:31 EDT
You can do whatever ungunking OpenPGP signatures.

All of the Red Hat signing keys are known to "work". Strip
whatever is not found in those keys.

There is still too little time before fc2 final to attempt anything
serious with automagic stripping (which solves the wrong problem
as well).
Comment 22 Marc Tamsky 2004-04-21 07:55:59 EDT
This is a showstopper of a bug in the core INTEGRITY CHECKING module


Checking package signatures can't happen without properly imported
keys to check them against.

I understand the statement "too little time before fc2 final", but in
the context of its status as a bug for more than a 1.5 YEARS... it
begs the imagination at what OTHER security related bugs have not yet
reached that critical prioritization level (read: Status: CLOSED).

Users that encounter a broken INTEGRITY CHECKING system can only serve
to reinforce the average person's supposition that "security checks
are just there to be ignored."

[I also loooove how this bug (or mabye its another) allows me to add
multiple copies of the same key into the RPM database... why would
anyone want n-copies of an identical key on their 'keychain'?]
Comment 23 Per Nystrom 2004-05-02 14:01:56 EDT
So nevermind the ungunking/stripping for now.  Can we at *least* have
rpm send an error or warning when you try to import an unclean key?
Comment 24 Warren Togami 2004-06-14 21:19:33 EDT
Comment 25 Per Nystrom 2004-06-24 01:38:28 EDT
Better still, I seem to remember a time when rpm just used keys as
they sat in the gpg keyring.  Maybe it would be simpler to return to
that. Is it really rpm's job to store public gpg keys, and is it a
good idea to have more than one store for the keys so that they might
get out of sync?

Comment 26 Jeff Johnson 2004-07-02 20:47:09 EDT
My marching orders are DEFERRED. Not my call, sorry.
Comment 27 Aleksey Nogin 2004-07-02 21:09:18 EDT
I do not see how the DEFERRED status (see comment #26) can coexist
with FC3 MUSTFIX one (see comment #24).
Comment 28 Leonard den Ottolander 2004-07-02 21:20:44 EDT
Quite right. I'm very interested to know who makes those decisions if
the developers obviously don't agree (among one another or with the
staff?). What is it that makes fixing this so difficult? (No, I'm not
going to attach a patch. Maybe one of you RH developers can.)
Comment 29 Warren Togami 2004-07-02 22:32:45 EDT
Comment #24 was my opinion based upon the general consensus that this
is an very bad problem.  To be fair however, it would be extremely
difficult to fix, and it is not a business requirement because Red Hat
supported products use only specific GPG keys which do not hit this
problem.  So Red Hat must defer putting engineering resources into
solving this problem the "right" way.  This does not mean that a well
implemented fix by an external contributor would be rejected.
Comment 30 Per Nystrom 2004-08-25 13:03:46 EDT
I would like to point out that Red Hat's own GPG keys do in fact have
this same problem if they are fetched from a public keyserver (those
keys have been signed many, many times by Red Hat).

On a side note, using a public keyserver is my preferred method for
fetching public keys to verify signatures because: 1. I don't have to
go searching through some convoluted website to find just the right
link from which to download the key: I just do "gpg --recv-keys
<keyID>" and I get what I need.  2. It lessens the chance that a
trojan horse attack could work.  If I get the rpm from one source and
the key from another, it's unlikely that both have been compromised in
such a way that they match up (and yes, I know that using key
signatures and a web of trust is preferable -- but then again, if the
key contains any signatures but a self-sig, those must be removed
before importing it to the rpm database).
Comment 31 Damian Menscher 2004-08-25 18:10:07 EDT
Just adding my name to the list of dissatisfied customers (we're 
paying for RHEL-3, and a SECURITY issue gets "deferred"??).  I see 
there are several other bug reports on the same issue also.  jbj: 
perhaps you can convince the higher-ups that this is important?
Comment 32 Nils Philippsen 2004-10-30 05:05:38 EDT
Damian (and all other RHEL customers lurking),

have you already opened a support ticket re: this issue? Open support
tickets will add to the "weight" of this problem as it is seen by the
people who will make the decisions, i.e. if RH support is aware of the
problem this is worth more to the manager who has to decide what Jeff
should deal with during his working hours than if Jeff or other
developers tell him that they have open bug reports where there are a
few people who claim to be RHEL customers, which is at best only
anecdotal evidence ;-).
Comment 33 Paul Stewart 2005-03-14 23:23:19 EST
Well, as of FC3, this problem still lives, for some value of "FC3 MUSTFIX CLOSED
Comment 34 Mark J. Cox (Product Security) 2005-07-29 06:43:17 EDT
*** Bug 164200 has been marked as a duplicate of this bug. ***
Comment 35 Paul Nasrat 2006-01-30 12:06:36 EST
*** Bug 131859 has been marked as a duplicate of this bug. ***
Comment 36 Jeff Johnson 2006-02-12 08:49:02 EST
I can't check signing, but I can check importing. The failure symptom is (or was) misidentifying
a subkey fingerprint with the pubkey fingerprint. Valid imports will have the pubkey fingerprint
in the Version: field.

    $ rpm --version
    RPM version 4.4.5

KeyID 0x54a2acf1:
    $ sudo rpm --import 0x54a2acf1
    $ rpm -q gpg-pubkey-54a2acf1
    $ sudo rpm -e gpg-pubkey-54a2acf1

KeyID 0x8df56d05:
    $ sudo rpm --import 0x8DF56D05
    $ rpm -q gpg-pubkey-8df56d05
    $ sudo rpm -e gpg-pubkey-8df56d05

KeyID 0xdfd3d769:
    $ sudo rpm --import 0xDFD3D769
    $ rpm -q gpg-pubkey-dfd3d769
    $ sudo rpm -e gpg-pubkey-dfd3d769

KeyID 0x1ac70ce6:
    $ sudo rpm --import 0x1ac70ce6
    $ rpm -q gpg-pubkey-1ac70ce6
    $ sudo rpm -e gpg-pubkey-1ac70ce6

KeyID 0x26752624:
    $ sudo rpm --import 0x26752624
    $ rpm -q gpg-pubkey-26752624
    $ sudo rpm -e gpg-pubkey-26752624

FWIW, the misidentifying fingerprints problem has been fixed since rpm-4.4.2 (almost 1.5 years).

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