Bug 89775

Summary:	"rpm --import" with multiple keys causes severe problems
Product:	[Retired] Red Hat Linux	Reporter:	James Ralston <ralston>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED WONTFIX	QA Contact:	Mike McLean <mikem>
Severity:	high	Docs Contact:
Priority:	high
Version:	9	CC:	barryn, mitr, scop, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-08-06 13:09:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Ralston 2003-04-28 06:56:27 UTC

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.

Comment 1 Jeff Johnson 2003-04-29 15:29:01 UTC

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.

Comment 2 James Ralston 2003-05-08 00:18:40 UTC

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.

Comment 3 Jeff Johnson 2003-05-08 13:34:25 UTC

No.

Comment 4 James Ralston 2004-06-26 00:31:29 UTC

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.