Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 457360 - Transactions that involve importing new signing keys cannot be completed
Summary: Transactions that involve importing new signing keys cannot be completed
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-31 06:54 UTC by Michel Alexandre Salim
Modified: 2014-01-21 23:03 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-08-08 13:48:19 UTC
Type: ---

Attachments (Terms of Use)

Description Michel Alexandre Salim 2008-07-31 06:54:18 UTC
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):

How reproducible:

Steps to Reproduce:
1. Add a new yum repository (e.g. Emacs XFT,
http://people.redhat.com/coldwell/emacs/repo/fedora/, or
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
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:

Comment 1 James Antill 2008-07-31 12:18:24 UTC
 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?

Comment 2 Jeff Johnson 2008-08-03 21:03:21 UTC
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.

Comment 3 Panu Matilainen 2008-08-04 09:56:00 UTC
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...

Comment 4 Panu Matilainen 2008-08-08 12:45:08 UTC
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.

Comment 5 James Antill 2008-08-08 13:48:19 UTC
 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?

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