Bug 1066044 - Downloading failed: Didn't install any keys
Summary: Downloading failed: Didn't install any keys
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 23
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1059896 1172349 (view as bug list)
Depends On:
Blocks: 1278969
TreeView+ depends on / blocked
 
Reported: 2014-02-17 14:52 UTC by JD Delancy
Modified: 2015-11-06 21:51 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1278969 (view as bug list)
Environment:
Last Closed: 2015-11-06 21:51:51 UTC
Type: Bug


Attachments (Terms of Use)

Description JD Delancy 2014-02-17 14:52:01 UTC
Description of problem:Trying to u pgraded to Fedora-20 using FedUP.  This error happens and I don't see any fixes:

warning: /var/tmp/system-upgrade/rpmfusion-nonfree/packages/rpmfusion-nonfree-release-20-1.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID b5f29883: NOKEY
Importing GPG key 0xB5F29883:
 Userid     : "RPM Fusion nonfree repository for Fedora (20) <rpmfusion-buildsys@lists.rpmfusion.org>"
 Fingerprint: a84d cf58 46cb 10b6 5c47 6c35 63c0 de8c b5f2 9883
 Package    : rpmfusion-nonfree-release-19-1.noarch (installed)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20

Downloading failed: Didn't install any keys

Any clues?  What can be done?  Using FedUP 0.8.0 <updated with fedup-0.8.0-3.fc20.noarch.rpm)



Version-Release number of selected component (if applicable):


How reproducible: Everytime I re-run FedUP


Steps to Reproduce:
1. Reboot
2. Open TERM; su root
3. Fedup --Network 20

Actual results: Remain in F19


Expected results: upgrading action


Additional info:

Comment 1 Will Woods 2014-02-17 18:02:34 UTC
Look at /var/log/fedup.log - it should tell you why the key(s) weren't imported.

Can you attach your fedup.log here?

Comment 2 Will Woods 2014-02-18 17:42:43 UTC
(user emailed me the fedup.log)

See the end of your fedup.log:

(II) fedup.yum:_GPGKeyCheck() repo 'rpmfusion-nonfree' wants to import key /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
(II) fedup.yum:check_keyfile() checking keyfile /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
(DD) fedup.yum:check_keyfile() keyfile owned by package rpmfusion-nonfree-release-0:19-1
(DD) fedup.yum:check_keyfile() package was signed with key cd30c86b
(II) fedup.yum:check_keyfile() REJECTED: key cd30c86b is not trusted by rpm
(II) fedup.yum:_GPGKeyCheck() no automatic trust for key %s

Your system doesn't trust the key that "rpmfusion-nonfree-release" was signed with. Probably you installed that package with "--nogpgcheck", so you never trusted the key.

The simplest solution - assuming you trust the existing package - is probably "yum reinstall rpmfusion-nonfree-release". This should make yum ask you if you trust the key it was signed with, and then fedup should import the F20 key for you.

Otherwise, you could manually trust the key:
   rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-19

If all else fails you can run fedup with --nogpgcheck, although that's not recommended.

Comment 3 Matthew 2014-02-25 18:48:13 UTC
I had the exact same error running Fedup from Fedora 19 to 20 as in this report.

Fedup ran throught the process downloading files for over an hour then failed at the last minute with the Error regarding the failure to install keys.
  it was rpmfusion-nonfree-release-19-1 package which was flagged as the problem with me too.

The tip to re-install the "rpmfusion-nonfree-release-19-1.noarch" package using yum, solved it for me.

After I reinstalled the "Rpmfusion-nofree-release-19-1.noarch" package and accepted the package and the key, I re-ran fedup and this time it finished off the small download it still required to get the rpmfusion-nonfree-fedora-20 package and key.

Then I got the message that it had Finished and to reboot to start the upgrade.

So hopefully now when I reboot it will run the upgrade.

Comment 4 Will Woods 2014-02-28 18:38:01 UTC
*** Bug 1059896 has been marked as a duplicate of this bug. ***

Comment 5 Jonathan Wakely 2014-04-07 22:56:04 UTC
I've hit this bug on two different F19 systems.

The instructions at http://rpmfusion.org/Configuration say to use --nogpgcheck so presumably lots of people have rpmfusion repos configured but don't trust the keys.

https://fedoraproject.org/wiki/FedUp#Will_packages_in_third_party_repositories_be_upgraded.3F and/or https://fedoraproject.org/wiki/Common_F20_bugs#Upgrade_to_Fedora_20_with_fedup_0.8_fails_due_to_GPG_key_problems should be updated to suggest reinstalling the rpmfusion-*-release packages, rather than saying it will work, or suggesting to disable rpmfusion.

Comment 6 Justin W. Flory (he/him) 2014-12-09 21:49:16 UTC
*** Bug 1172349 has been marked as a duplicate of this bug. ***

Comment 7 Justin W. Flory (he/him) 2014-12-09 21:56:00 UTC
(In reply to Will Woods from comment #2)
> (user emailed me the fedup.log)
> 
> See the end of your fedup.log:
> 
> (II) fedup.yum:_GPGKeyCheck() repo 'rpmfusion-nonfree' wants to import key
> /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
> (II) fedup.yum:check_keyfile() checking keyfile
> /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-20
> (DD) fedup.yum:check_keyfile() keyfile owned by package
> rpmfusion-nonfree-release-0:19-1
> (DD) fedup.yum:check_keyfile() package was signed with key cd30c86b
> (II) fedup.yum:check_keyfile() REJECTED: key cd30c86b is not trusted by rpm
> (II) fedup.yum:_GPGKeyCheck() no automatic trust for key %s
> 
> Your system doesn't trust the key that "rpmfusion-nonfree-release" was
> signed with. Probably you installed that package with "--nogpgcheck", so you
> never trusted the key.
> 
> The simplest solution - assuming you trust the existing package - is
> probably "yum reinstall rpmfusion-nonfree-release". This should make yum ask
> you if you trust the key it was signed with, and then fedup should import
> the F20 key for you.
> 
> Otherwise, you could manually trust the key:
>    rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-19
> 
> If all else fails you can run fedup with --nogpgcheck, although that's not
> recommended.

I would just like to chime in and say that this solution worked beautifully for me. I guess I never properly imported the right keys for RPM Fusion when I originally installed it on my laptop. However, a simple reinstall of "rpmfusion-nonfree-release" fixed this issue for me completely. My laptop is currently in the process of upgrading to Fedora 21, hooray!

I would like to propose this little problem being added to the Wiki as part of the FAQ / troubleshooting sections, as it seems to be a recurring issue. If I can find the place for it, I will add it in myself, but I am not as familiar with the order of the wiki as other users are, I am sure.

Comment 8 Will Woods 2014-12-10 00:52:55 UTC
There's no (secure) way for fedup to automatically establish this trust for you, but we should probably fall back to yum's "Importing GPG key, is this ok [y/N]" dialog in this case.

Comment 9 Will Woods 2014-12-10 21:37:14 UTC
Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d

Should be in the next fedup package (fedup-0.9.1-2 or higher).

Comment 10 Yuriy Lapitskiy 2015-01-04 12:07:09 UTC
(In reply to Will Woods from comment #9)
> Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d
> 
> Should be in the next fedup package (fedup-0.9.1-2 or higher).

Isn't this unsecure when we ask the user if they trust the key. GPG key couldn't be verified by just looking at it.

Besides there's always a "--nogpgcheck" option.

Maybe it's good to have an GPG key import on-the-go instead of rerunning fedup from the beginning after downloading the key manually. Maybe even ask the user a link to download a GPG key.

Comment 11 Will Woods 2015-01-05 21:01:36 UTC
(In reply to Yuriy Lapitskiy from comment #10)
> (In reply to Will Woods from comment #9)
> > Implemented in git: https://github.com/wgwoods/fedup/commit/47a824d
> > 
> > Should be in the next fedup package (fedup-0.9.1-2 or higher).
> 
> Isn't this unsecure when we ask the user if they trust the key. GPG key
> couldn't be verified by just looking at it.

If you're asking if it's insecure to ask the user to trust a key... that's a much bigger problem, and well outside the scope of fedup. (This is basically the legendary Bug #998, if you're interested.)

To be clear, fedup has *one* special rule for GPG keys.
fedup will *only* automatically import a key if:

  a) it's a file on the local disk, and
  b) the file is owned by a package that was signed by a trusted key, and
  c) the file hasn't been modified since being installed.

In short: if the new key came out of a package you trust, that key must also be trustworthy, and so fedup will import it. Otherwise, fedup does nothing.

> Maybe it's good to have an GPG key import on-the-go instead of rerunning
> fedup from the beginning after downloading the key manually.

Right, that's what was added in git commit 47a824d. If a key can't be auto-imported, fedup will now fall back to yum's default key-handling behavior (show the user some key info, ask if they trust it).

Whether or not that behavior is correct is up to yum, not fedup.

> Maybe even ask the user a link to download a GPG key.

That link is already in the .repo file. But most repos ship their keys inside a "repo-release" package and use "gpgkey=file:///...", because (AFAIK) yum doesn't download GPG keys for you.

But again, that's up to yum, not fedup.

Comment 12 Fedora End Of Life 2015-05-29 10:57:07 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Tadej Janež 2015-05-29 16:10:45 UTC
Fixed in v0.9.2, which is in Fedora 21.

Comment 14 James (purpleidea) 2015-11-04 06:52:45 UTC
I can confirm I just experienced this in Fedora 22, when trying to upgrade to Fedora 23:

james@computer:~$ sudo dnf system-upgrade download --releasever=23 --allowerasing

(5489/5489): libreoffice-core-5.0.3.1-1.fc23.x8 141 kB/s |  74 MB     08:56
--------------------------------------------------------------------------------
Total                                           868 kB/s | 2.6 GB     53:19
warning: /var/lib/dnf/system-upgrade/efivar-libs-0.21-1.fc23.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 34ec9cba: NOKEY
Importing GPG key 0x34EC9CBA:
 Userid     : "Fedora (23) <fedora-23-primary@fedoraproject.org>"
 Fingerprint: EF45 5106 80FB 0232 6B04 5AFB 3247 4CF8 34EC 9CBA
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64
Is this ok [y/N]: The downloaded packages were saved in cache till the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Didn't install any keys
james@computer:~$ sudo rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64

I manually ran this import command to fix the issue.

Comment 15 Adam Williamson 2015-11-04 07:55:19 UTC
er...it doesn't look like you answered 'y' to the question whether you wanted to import the key.

Comment 16 James (purpleidea) 2015-11-04 09:15:38 UTC
(In reply to awilliam@redhat.com from comment #15)
> er...it doesn't look like you answered 'y' to the question whether you
> wanted to import the key.

I had the same thought, however it never prompted me, the script just exited. Either that or it had a very short timeout and I missed it somehow.

Comment 17 Adam Williamson 2015-11-04 17:26:31 UTC
When you run dnf in some sort of non-interactive way it by default answers 'no' to all questions, you can pass '-y' to make it answer 'yes'. Possibly this is happening when you run through sudo, is my only guess? I think I usually run the dnf command directly as root, not sure about other testers.

Comment 18 Will Woods 2015-11-06 21:51:51 UTC
...DNF assuming "no" on key import (if run through sudo) is a totally different problem (in a completely different package!) than the original bug here.

DNF plugins can't (AFAIK) control how the key import prompt works, so it's not really even possible for me to fix this in dnf-plugin-system-upgrade.

Therefore I've filed bug 1278969 against dnf to track the problem mentioned in comment #14 and onward.

Re-closing this bug as in comment #13.


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