Red Hat Bugzilla – Bug 457360
Transactions that involve importing new signing keys cannot be completed
Last modified: 2014-01-21 18:03:42 EST
Description of problem: If some of the packages in a yum transaction come from a newly-seen repository, yum would prompt the user to import the signing key. Up to Fedora 9, the transaction then proceeds; now, yum would complain that the public key is not installed and then abort. Repeating the transaction, now that the key is imported, works as expected. Version-Release number of selected component (if applicable): yum-3.2.17-2.fc10.noarch How reproducible: Always Steps to Reproduce: 1. Add a new yum repository (e.g. Emacs XFT, http://people.redhat.com/coldwell/emacs/repo/fedora/, or that-repository-that-shall-not-be-named) 2. Install a package from that repository Actual results: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID a109b1ec Importing GPG key 0xA109B1EC "Livna.org rpms <rpm-key@livna.org>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-livna Is this ok [y/N]: y Public key for libdvbpsi-0.1.6-2.lvn9.x86_64.rpm is not installed Expected results: Last line should not be seen, transaction should proceed normally Additional info:
Well I'm assuming that Fed-9 isn't broken ... so that implies that rpm or the rpm bindings aren't doing the right thing. ffesti do we need to change anything when running on the new rpm?
Hmmm ... If pubkeys in rpmdb are not being seen until next transaction, there's a fair to middling chance that other headers are being lost as well. pubkeys in a rpmdb are no different than any other package header when resident in a rpmdb. E.g. see bz #442445 which appears to be caused by certain package headers gone AWOL.
rpmtsImportPubkey() semantics got (unintentionally) changed by the new keyring interface used for signature checking, and FWIW it has zero to do with headers. Will fix...
rpm-4.5.90-0.git8461.1 in rawhide now has the basic fix for this, ie rpmtsImportPubkey() makes the freshly imported key available to that transactions keyring. However... yum has a number of transaction set objects open at the time of import and actually imports the keys on a different transaction set than is used for checking the signatures. That used to work when the rpmdb was used as a real-time keyring, but that's not the case anymore, even though pubkeys *might* be stored in the rpmdb. The backwards compatible way to deal with this is to just import the keys on the same transaction set as is used for checking the signatures. See below for a quick and dirty hack that makes it "work", but the patch is NOT correct as it imports on the supposedly read-only ts: --- a/yum/__init__.py +++ b/yum/__init__.py @@ -2786,7 +2786,7 @@ class YumBase(depsolve.Depsolve): keyurls = repo.gpgkey key_installed = False - ts = rpmUtils.transaction.TransactionWrapper(self.conf.installroot) + ts = self.rpmdb.readOnlyTS() for keyurl in keyurls: keys = self._retrievePublicKey(keyurl) Somebody more familiar with the yum codebase can fix it up properly faster than I can... so over to yum.
I think the only caveat that we need to make sure of is that C-c still works in all the right places. Specifically make sure this is fine wrt. commit a726a9d7652fff46000b5ac19de50416ef342719 ... but I'm pretty sure it is (download/key-import happens after depsolving). I've checked the patch into upstream, and I'll keep and eye on it. I assume this means we need to do a new rawhide fairly soon?