Description of problem: Freshly installed F19 system. yum-cron daily fails to apply updates with: warning: /var/cache/yum/x86_64/19/updates-testing/packages/libffi-3.0.13-4.fc19.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fb4b18e6: NOKEY Public key for libffi-3.0.13-4.fc19.x86_64.rpm is not installed Importing GPG key 0xFB4B18E6: Userid : "Fedora (19) <fedora>" Fingerprint: ca81 b2c8 5e4f 4d4a 1a3f 7234 0747 7e65 fb4b 18e6 Package : fedora-release-19-0.5.noarch (@anaconda) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 The following updates will be applied on vmf19.cora.nwra.com: ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: freetype x86_64 2.4.11-6.fc19 updates-testing 383 k libffi x86_64 3.0.13-4.fc19 updates-testing 28 k ntfs-3g x86_64 2:2013.1.13-5.fc19 updates-testing 268 k ntfsprogs x86_64 2:2013.1.13-5.fc19 updates-testing 253 k polkit x86_64 0.111-2.fc19 updates-testing 162 k selinux-policy-targeted noarch 3.12.1-47.fc19 updates-testing 4.0 M unzip x86_64 6.0-9.fc19 updates-testing 166 k Updating for dependencies: selinux-policy noarch 3.12.1-47.fc19 updates-testing 261 k Transaction Summary ================================================================================ Upgrade 7 Packages (+1 Dependent package) Updates failed to install with the following error message: ["Didn't install any keys"] Version-Release number of selected component (if applicable): yum-cron-3.4.3-91.fc19.noarch
Since yum-cron does not run interactively we can't ask the user if the key is okay, so the key is not imported. Had we set opts.assumeyes=True the key would get imported unconditionally, but that has obvious security implications. Adding assumeyes option to yum-cron.conf is trivial, but I'd like to hear more comments on this first.
*** Bug 983136 has been marked as a duplicate of this bug. ***
I tried adding: [base] assumeyes = True to /etc/yum/yum-cron.conf, but that didn't help. Is that the right option?
We have to also add some glue code to yum-cron.py.. and maybe also change the option name to something more meaningfull, eg "import_new_keys=True"?
Yes, a better name would be good.
Is there anything I can do to help get this fixed?
Sorry, this was fixed upstream and released as 3.4.3-108 with other changes.. Basically we just apply everything in [main] section to override yum config, so since -108, you can just use what you wrote in comment #3. There's a comment in yum-cron.conf.
Okay, so I'm just waiting for this to make it to F19 then.
@Orion: I see there's a build in koki: https://koji.fedoraproject.org/koji/buildinfo?buildID=460846 doesn't look like updates-testing has been requested yet. FYI, you can upgrade with: sudo rpm -Uhv http://kojipkgs.fedoraproject.org//packages/yum/3.4.3/108.fc19/noarch/yum-3.4.3-108.fc19.noarch.rpm sudo rpm -Uhv http://kojipkgs.fedoraproject.org//packages/yum/3.4.3/108.fc19/noarch/yum-cron-3.4.3-108.fc19.noarch.rpm for testing purposes. I don't think I'll use it myself, in case the repo gets compromised. I'd love to see 'assumeyes = 7d' or some such thing in the future to accept new keys after some reasonable length of time for humans to detect a repo compromise; both are risks, it's just a matter of choosing the best compromise for a given system.
So, looks like this in f19 but not f20? yum.noarch 3.4.3-111.fc19 @updates yum.noarch 3.4.3-106.fc20 @anaconda That's a broken upgrade path.
This seems to be broken again with yum-3.4.3-153.fc21.noarch
Or maybe not. Today it worked.