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-----
I've confirmed that this behavior does not occur in 4.4.2-48 on RHEL 5.3.
Easily verified, this is indeed a regression. Thanks for reporting.
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.
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