Bug 90952

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.

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.

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x54A2ACF1

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.

Created attachment 91884 [details]
rpmio/tring ../pubkey.54a2acf1

Thanks for pointer. Attached is the output of rpmio/tring
for the pubkey 0x54a2acf1.

Created attachment 91885 [details]
rpmio/tring togami.key

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.

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.

Created attachment 93610 [details]
rpm --import'ing this goes wrong

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

*** Bug 68291 has been marked as a duplicate of this bug. ***

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

Can anyone suggest a script or source code that takes a key and strips
it to be importable?

No way can this be done for fc2, you're way past my rpm devel
cycle.

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.

No one is saying the problem does not exist.

The bug was resolved to DEFDERRED for the reasons stated.

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.

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?

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

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?

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

This is a showstopper of a bug in the core INTEGRITY CHECKING module
of the PACKAGE MANAGEMENT system.

It is HIGHLY QUESTIONABLE from a SECURITY POLICY to continue to FORCE
USERS TO BYPASS SECURITY checks.

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'?]

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?

FC3 MUSTFIX

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?

My marching orders are DEFERRED. Not my call, sorry.

I do not see how the DEFERRED status (see comment #26) can coexist
with FC3 MUSTFIX one (see comment #24).

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

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

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?

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

Well, as of FC3, this problem still lives, for some value of "FC3 MUSTFIX CLOSED
DEFFERRED"

*** Bug 164200 has been marked as a duplicate of this bug. ***

*** Bug 131859 has been marked as a duplicate of this bug. ***

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
    gpg-pubkey-54a2acf1-3e38e07d.pubkey
    $ sudo rpm -e gpg-pubkey-54a2acf1

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

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

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

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

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