Bug 457360 - Transactions that involve importing new signing keys cannot be completed
Transactions that involve importing new signing keys cannot be completed
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-31 02:54 EDT by Michel Alexandre Salim
Modified: 2014-01-21 18:03 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-08 09:48:19 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 Michel Alexandre Salim 2008-07-31 02:54:18 EDT
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:
Comment 1 James Antill 2008-07-31 08:18:24 EDT
 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 17:03:21 EDT
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 05:56:00 EDT
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 08:45:08 EDT
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 09:48:19 EDT
 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.