Bug 493777 - rpm --import gets the key id wrong
rpm --import gets the key id wrong
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.3
i686 Linux
low Severity high
: rc
: ---
Assigned To: Panu Matilainen
Petr Sklenar
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-02 23:06 EDT by Micah Cowan
Modified: 2010-02-23 07:24 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:41:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Micah Cowan 2009-04-02 23:06:07 EDT
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 16:36:00 EDT
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 05:55:48 EDT
Easily verified, this is indeed a regression. Thanks for reporting.
Comment 5 Micah Cowan 2009-04-21 16:20:01 EDT
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 07:41:09 EDT
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

Note You need to log in before you can comment on or make changes to this bug.