Red Hat Bugzilla – Bug 60611
rpm --checksig sometimes not safe
Last modified: 2008-05-01 11:38:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13 i686)
Description of problem:
The rpm tool will under certain conditions result in "gpg OK" while the keys
used for the signatures may not have been explicitly flagged by the user as to
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install the rpms for gnupg and rpm (emtpy gnupg keyring)
2. Specify a keyserver in ~/.gnupg/options
3. Verify an rpm with rpm --checksig
Actual Results: If the public key of the signature on the rpm file is present
on the keyserver, then the public key is automatically retrieved from the
keyserver, used for verifying the signature on the rpm file, and the result of
rpm --checksig says "gpg OK" while the user has never explicitly flagged the
public key as to be trusted.
Expected Results: I expected a "gpg NOT OK". I would expect rpm to use the
trustdb of gnupg. I have the impression that this is not the case. The result of
"rpm --checksig" should somehow warn the user that the key was automatically
imported but that the key is not in the trustdb, so that the verification of the
signature should not be blindly trusted.
I would suggest the following modifications as solution:
First, the option no-auto-key-retrieve should by default be present in
~/.gnupg/options and a warning should be included in the remarks near the
keyserver option in the same file.
Second, I would make rpm use the trustdb of gnupg, or somehow make gnupg skip
the automatically retrieving of missing keys.
I'd very much appreciate some feedback on this bug report, since I don't feel
quite completely sure whether I'm correctly using gnupg and rpm. Maybe it's not
a bug at all. If so, my sincere apologies.
This is neither a bug or a feature, but rather
a design choice to return 0 (i.e. success) with missing keys,
further info regarding missing keys returned with
-v flag specified when first implemented.
FWIW, rpm-4.0.4 returns non-zero (i.e. failure)
when a key was not found.
-----BEGIN PGP SIGNED MESSAGE-----
Your answer surprises me. During my test I downloaded a random rpm,
packaged and signed by some unknown packager. The pgp key of the
signature on the rpm was not yet in my gnupg keyring. Then I ran
rpm --checksig for the rpm. What happened? The key was automatically
retrieved from the keyserver and added to my keyring. At that point,
the key was no longer "missing" in my keyring, but was not yet
included in my personal web of trust, so should not be trusted yet.
Then the key is used for the signature verification on the rpm. The
signature is evaluated as valid, but we still don't know anything of
the key owner. Then rpm --checksig simply says "gpg OK" without any
warning on the missing PGP trust path. The rpm, the key, and the
signature on the rpm may come from anyone, including trojan horse
builders. This feels to me as a security bug in rpm, because of
insecure/wrong use of PGP. I hope that this behaviour is not due
to some design choice, and that I've missed some point somewhere...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Again, a design choice. rpm -Kvv displays exactly
the info returned by pgp/gpg helpers, but NOKEY and
UNTRUSTED returns from helpers were not considered
verification failures by rpm.