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 be trusted. Version-Release number of selected component (if applicable): How reproducible: Always 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. Additional info: 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----- Hash: SHA1 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... Bart Martens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8gpBXZ4lamfum7PERAp3YAKCXAJnqAEV1J7utNUz0VpEBvKwenQCaA7y7 BGU8CbWuqTDAQEQTDk60mdU= =Lchd -----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.