Bug 493777

Summary:	rpm --import gets the key id wrong
Product:	Red Hat Enterprise Linux 5	Reporter:	Micah Cowan <micah>
Component:	rpm	Assignee:	Panu Matilainen <pmatilai>
Status:	CLOSED ERRATA	QA Contact:	Petr Sklenar <psklenar>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.3	CC:	bperkins, cmoore, psklenar
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-02 11:41:09 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 Micah Cowan 2009-04-03 03:06:07 UTC

Description of problem:
rpm --import determines an erroneous key id for a given GPG key, resulting in an inability to find that key at a future time.
This is a regression in behavior over RHEL 5.2.

Version-Release number of selected component (if applicable):
4.4.2.3-9.el5

How reproducible:
100% of the time.

Steps to Reproduce:
1. Import the key given in "Additional Info" using "rpm --import" (which comes from http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub).

Actual results:
rpm creates a new package header, "gpg-pubkey-a6406560-4803fe57".
(You can verify that the key id portion is incorrect by examining the key with gpg.)

Expected results:
rpm creates the package header "gpg-pubkey-66fd4949-4803fe57".
(This is what it does in previous versions of Red Hat).

Additional info:

The only code change I can find in rpm itself would be *nss.patch. Otherwise, it could be a change to a library rather than rpm itself...

Here's the key

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (GNU/Linux)

mI0ESAP+VwEEAMZylR8dOijUPNn3He3GdgM/kOXEhn3uQl+sRMNJUDm1qebi2D5b
Qa7GNBIlXm3DEMAS+ZlkiFQ4WnhUq5awEXU7MGcWCEGfums5FckV2tysSfn7HeWd
9mkEnsY2CUZF54lyKfY0f+vdFd6QdYo6b+YxGnLyiunEYHXSEo1TNj1vABEBAAG0
QlZNd2FyZSwgSW5jLiAtLSBMaW51eCBQYWNrYWdpbmcgS2V5IC0tIDxsaW51eC1w
YWNrYWdlc0B2bXdhcmUuY29tPoi8BBMBAgAmBQJIA/5XAhsDBQkRcu4ZBgsJCAcD
AgQVAggDBBYCAwECHgECF4AACgkQwLXgq2b9SUkw0AP/UlmWQIjMNcYfTKCOOyFx
Csl3bY5OZ6HZs4qCRvzESVTyKs0YN1gX5YDDRmE5EbaqSO7OLriA7p81CYhstYID
GjVTBqH/zJz/DGKQUv0A7qGvnX4MDt/cvvgEXjGpeRx42le/mkPsHdwbG/8jKveY
S/eu0g9IenS49i0hcOnjShGIRgQQEQIABgUCSAQWfAAKCRD1ZoIQEyn810LTAJ9k
IOziCqa/awfBvlLq4eRgN/NnkwCeJLOuL6eAueYjaODTcFEGKUXlgM4=
=bXtp
-----END PGP PUBLIC KEY BLOCK-----

Comment 1 Micah Cowan 2009-04-03 20:36:00 UTC

I've confirmed that this behavior does not occur in 4.4.2-48 on RHEL 5.3.

Comment 2 Panu Matilainen 2009-04-09 09:55:48 UTC

Easily verified, this is indeed a regression. Thanks for reporting.

Comment 5 Micah Cowan 2009-04-21 20:20:01 UTC

Any hints for workarounds? Right now we (VMware) are recommending people disable signature checks... we've already issued a knowledge base article for that, but obviously it'd be better to fix the package registry so the proper key id may be found. Is there a (user-friendly) means to "rename" the "package", without going into what amounts (especially to an end-user) to risky, deep voodoo (such as directly editing a file, in a fashion that has the potential to royally screw up their system if they're not careful)? Thanks.

Comment 9 errata-xmlrpc 2009-09-02 11:41:09 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1371.html