Red Hat Bugzilla – Bug 89775
"rpm --import" with multiple keys causes severe problems
Last modified: 2005-10-31 17:00:50 EST
Description of problem: The --import flag imports the public key in the specified key file into the RPM database. The --import flag assumes that the public key file contains one and only one public key. If the specified public key file in fact contains multiple public keys, rpm corrupts the rpm database. Version-Release number of selected component (if applicable): rpm-4.2-0.69 How reproducible: Create a key file which contains multiple public keys; e.g.: gpg --export --armor db42a60e 897da07a >key Importing this key file will corrupt the RPM database: rpm --import key Actual results: All attempts to enumerate packages in the rpm database return an error something like this: error: rpmdbNextIterator: skipping h# 1376 Header V3 DSA signature: BAD, key ID db42a60e You can recover the rpmdb by prepending "gpg-pubkey-" to the key ID contained in the error message, and then erasing that pseudo-package. E.g.: rpm -e gpg-pubkey-db42a60e However, if you run rpm --rebuilddb while the database is in the corrupted state, THE DATABASE IS COMPLETELY DESTROYED. (Specifically, all information stored in /var/lib/rpm/Packages is discarded when the database is rebuilt.) Expected results: THIS SHOULD NOT HAPPEN. Either rpm should refuse to --import key files which contain multiple public keys (the quick fix), or rpm should correctly import all public keys in the supplied key file, without corrupting the database (the Correct fix). Additional info: There are two factors which make this bug horribly, horribly nasty: First, people familiar with GnuPG will find nothing unusual about putting multiple public keys in the same key file, as all PGP implementations I've used can cope with this. (In fact, I believe this is required by the OpenPGP standard.) Second, with all the locking problems in rpm-4.x, the mantra of "rm -f /var/lib/rpm/__db.*; rpm --rebuilddb" is being chanted far and wide. This action is *precisely* the action that will completely destroy the corrupted rpm database.
The database is not corrupted, signatures on headers are failing to verify. Yes, --rebuilddb will skip all headers whose signatures fail to verify. This is deemed a feature, but I can see why you would disagree. Don't do that is basically the answer. Keyring management is up to the user. You can reconstruct the database from the list of packages that were installed located in /var/log/rpmpkgs. Download, rename /var/lib/rpm/Packages, and then install with rpm -Uvh --justdb --noscripts --notriggers --nodeps --noorder *.rpm Deferred to somewhen for multiple pubkey imports.
We can argue about whether the database was technically "corrupted" or not, but it's irrelevant: from my point of view, I performed a reasonable operation, and as a result, the RPM database was left in a state where it was useless, and virtually no operations on it succeeded. The most reasonable step I thought of to try next (running --rebuilddb), for all intents and purposes, COMPLETELY DESTROYED the database. Metaphorically speaking, I was driving down the road in my car, and when I attempted to open my sunroof and roll down the window at the same time, my car died. I pulled it off to the side of the road, and when I pulled the hood release, my car exploded in a massive fireball, leaving only a few scraps of rubber behind. I'm not asking you to put my car back together--I did that already. ;) Similarly, I don't need to hear "don't do that", as I already learned that the hard way. I'm asking you to push out an errata update of RPM that, at a minimum, bails out with an error message if the user tries to import multiple public keys at the same time. In other words, don't tell people "don't do that"; make rpm tell people "I'm sorry Dave, but I can't let you do that." Because, IMHO, this bug isn't just a minor inconvenience; it's a hidden pit with big sharp spikes in the bottom.
No.
I tested this again on rpm-4.2-0.69 (on RHL9), and it appears that --import will only take the first key out of the file, thereby avoiding this problem. Unless someone wants this bug to be open (I wasn't the one who re-opened it), I will go ahead and close it out within the next few days.