Bug 68291

Actually, it seems to be even worse - it appears that even for that one key that
made it into  the "version" field when importing a multi-key file, it still
would not work correctly. Namely, rpm recognizes it has the key, but "rpm -Kv"
would consider all signatures made with it top be bad!

ATM, rpm supports only a subset of all possible OpenPGP
package formats.

Please add an attachment/pointer to a pubkey and package signed
with that key if you wish a more complete implementation.

Otherwise, just extract the keys and use gpg directly to
verify. Shell script that does this attached.

Created attachment 64385 [details]
Verify header+payload package signature using gpg

Let me try being a little more specific.

To reproduce:

a) gpg --export --armor id1 id2 [id3 ...] > /tmp/pubkeys
b) rpm --import /tmp/pubkeys
c) rpm -Kv on packages signed with id1 and id2.

Expected: 
 - best case: everything works (for example, as in (1-3) on the initial report).
 - minimal: rpm rejects the key file in (b) as unsupported.

Actual:
 - in (b) rpm would create *one* gpg-pubkey package with one of the ids (let's
call it idx) as the "version". Usually idx=id1, but I saw idx=id2 too.
 - in (c) for packages signed with ids other than idx rpm would say the key is
missing (bad)
 - in (c) for packages signed with idx rpm would say the signature is wrong
(very bad).

In short, I understand that some formats may be unsupported by rpm, but at
minimum rpm should recognize those formats and reject --importing them.

I'm not disagreeing, I'm only asking for
a pointer to a public key and a package
that was signed with that key so that I
can see exactly what needs to be done.

This is getting weirder every time I try --import'ing something. I tried
importing a keyfile (I'll attach it in a second) that contained the key 897DA07A
(rawhide@redhat) which was signed by DB42A60E (secutity@redhat). But importing
that keyfile resulted in gpg-pubkey-db42a60e-3c979aa4 "package" being added
which not only means that it was still unable to check signatured on packages
signed by 897DA07A (I assume you have plenty of those for tesing ;-), but also
(I would guess, have not actually tried it) would interfere with sigchecking of
packages singed by the "real" db42a60e.

Only when I removed the DB42A60E signature and --imported a "plain" 897DA07A
key, things worked out as expected...

Created attachment 64647 [details]
A keyfile of 897DA07A with DB42A60E sig, gets imported incorrectly.

Created attachment 64648 [details]
897DA07A key w/o DB42A60E sig, gets imported correctly.

Can you give me a pointer to a package signed
with the key that rpm does not understand?
Any package will do, I usually use the time package,
it's teensy.

BTW, I enhanced rpm -qi in rpm-4.1-0.46 to display:

Signature   : DSA/SHA1, Tue 25 Jun 2002 01:42:34 PM EDT, Key ID fd372689897da07a

OK, may be I was not clear enough. The problem is not with signatures, the
problem is with the --import not understanding some files (or even worse
-misunderstanding them), such as the "key-with-sig" file attached here. And once
"--import" messes things up, signature checking suffers badly, but it's not its
fault for not being able to figure out that things are already in a pretty
inconsistent state.

Below is a sequence of steps that should be 100% reproducible on a machine with
the same version of rpm and using the "key-with-sig" file attached here. My
comments start with ">>>" (and are placed below the command and output being
commented).

# rpm -q rpm
rpm-4.1-0.34
# rpm -e --allmatches gpg-pubkey
>>> The above is just to make sure we start in a clean state.
# rpm --import key-with-sig
>>> The import above non doing the right thing is what causes 
>>> *all* the problems below. All the stuff below is there
>>> just to *demonstrate* what problems arise out of this bad --import
# rpm -q gpg-pubkey
gpg-pubkey-db42a60e-3c979aa4
>>> OK, so the largest issue is that --import thought that the 
>>> "key-with-sig" contained the "db42a60e" key, while in fact in
>>> contained "897DA07A" key which is *signed* by "db42a60e" 
# gpg --import /tmp/key-with-sig
gpg: key 897DA07A: not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
>>> The above was to verify that the file indeed contains "897DA07A" 
>>> and *not* "db42a60e" (as rpm --import mistakenly thought).
# rpm -Kvv
ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/basesystem-7.0-2.noarch.rpm
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: logging into ftp.redhat.com as ftp, pw (username)
D: file is not regular -- skipping size check
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
D: ========== DSA pubkey id 219180cddb42a60e
ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/basesystem-7.0-2.noarch.rpm:
    MD5 digest: OK (44e289b35d9d09c7b1d4e64583f2324b)
    V3 DSA signature: BAD, key ID db42a60e
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: removed  db environment /var/lib/rpm/Packages
>>> The signature is actually good, but rpm now thinks it's bad since
>>> it does not really have the public key to check it against!
# rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
>>> Let's see what happens if we import the correct thing.
# rpm -q gpg-pubkey
gpg-pubkey-db42a60e-3c979aa4
gpg-pubkey-db42a60e-37ea5438
# rpm -Kvv
ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/basesystem-7.0-2.noarch.rpm
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: logging into ftp.redhat.com as ftp, pw (username)
D: file is not regular -- skipping size check
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
D: ========== DSA pubkey id 219180cddb42a60e
ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/basesystem-7.0-2.noarch.rpm:
    MD5 digest: OK (44e289b35d9d09c7b1d4e64583f2324b)
    V3 DSA signature: BAD, key ID db42a60e
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: removed  db environment /var/lib/rpm/Packages
>>> Still no luck - rpm seems to check the package signature against
>>> the "broken" gpg-pubkey-db42a60e-3c979aa4 instead of the correct
>>> public key (which is probably *not* a bug on its own - the first
>>> matching key just takes precedence).
# rpm -Kvv
ftp://ftp.redhat.com/pub/redhat/linux/beta/limbo/en/os/i386/RedHat/RPMS/basesystem-7.0-5.noarch.rpm
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: logging into ftp.redhat.com as ftp, pw (username)
D: file is not regular -- skipping size check
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
ftp://ftp.redhat.com/pub/redhat/linux/beta/limbo/en/os/i386/RedHat/RPMS/basesystem-7.0-5.noarch.rpm:
    Header V3 DSA signature: NOKEY, key ID 897da07a
    MD5 digest: OK (825f8e7b39611f3d6c9a4cc41da024b5)
    V3 DSA signature: NOKEY, key ID 897da07a
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: removed  db environment /var/lib/rpm/Packages
>>> The above just demonstrates another consequence of the borked
>>> --import - rpm does have the public key 897da07a (in
>>> gpg-pubkey-db42a60e-3c979aa4), but since it was misplaced, rpm
>>> thinks the key is not there.

Hope that makes it clearer...

Yes, there is no full-blown support for all
possible OpenPGP packets. Known, agreed,
identified, yes, yes, yes.

Now can you *please* sign some package with
the key that does not import correctly, and
give me a pointer to that package, so that
I can fix the problem? The code paths that
need to be fixed are common throughout,
and it's the parser that needs to be fixed,
not just --import, which uses the parser.

> Now can you *please* sign some package with
> the key that does not import correctly, and
> give me a pointer to that package, 

I am still do not understand what exactly you need and how what you need is
different from what you already have: a key-with-sig file containing aa version
of the RedHat's rawhide key that does not import correctly and
ftp://ftp.redhat.com/pub/redhat/linux/beta/limbo/en/os/i386/RedHat/RPMS/basesystem-7.0-5.noarch.rpm
 - a package correctly signed with that key.

P.S. Possibly the reason I do not understand what you need is because I do not
understand why you need it (and while this understanding is not necessary if you
give me some clear instructions, it might help). The parser clearly misparses
the key-with-sig file, is not that enough to figure out what goes wrong?

Ick, I meant to delete that comment. After re-reading
I think I have enough info to reproduce, but "Save Changes"
got pressed in the interim. Again, apologies.

What I was hoping for is a reproducible test case
for signature verification, not possible when working
with someone else's pubkey. But I think I can fix the
parse problem with just the pubkey.

> "Save Changes" got pressed in the interim

Done that myself more than once, no need to apologize.

> What I was hoping for is a reproducible test case
> for signature verification,

I haven't seen one yet - all I've seen so far were --import's faults... But once
--import is fixed, it will be easier to pass "weird" data to sig verification
and I'll be sure to test it...

> not possible when working with someone else's pubkey.

Well, that's why I tried my best creating a test case using Red Hat's key - but
in case you do not have sufficient access to it, I would imagine it should be
relatively easy to reproduce the problem using your own key...

Yup, pubkey signid parameter was being parsed from the generic,
rather than the positive, certification signature subpkt.

Fixed in rpm-4.1-0.66, building soon.

This bug is still there in Fedora Core (rpm-4.2.1-0.30). For example,
key 9D6B4012: "Arjan van de Ven <arjanv>" gets imported as
gpg-pubkey-92f0fc09-3f23efee on my system (will attach relevant files
in a moment) :-(

Created attachment 96105 [details]
A keyfile with the key 0x9D6B4012: (Arjan van de Ven <arjanv>) that does not get imported correctly.

To reproduce:

1) Verify that the file contains the key I say ot does:

% gpg --import /tmp/9d6b4012

2) Verify that we started in a sufficiently "clean" state:

# rpm -q gpg-pubkey-92f0fc09 gpg-pubkey-9d6b4012
package gpg-pubkey-92f0fc09 is not installed
package gpg-pubkey-9d6b4012 is not installed

3) Import the key:

# rpm --import /tmp/9d6b4012

4) Expected - gpg-pubkey-9d6b4012 is there, gpg-pubkey-92f0fc09 is not.

Actual:

# rpm -q gpg-pubkey-92f0fc09 gpg-pubkey-9d6b4012
gpg-pubkey-92f0fc09-3f23efee
package gpg-pubkey-9d6b4012 is not installed

Probably it is important this get fixed, but still setting severity to
normal. (See the help page for details on when to set severity to high.)

Aleksey, do you think this can be closed a dup while we track via bug
90952?

*** This bug has been marked as a duplicate of 90952 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.