Bug 1224908

Summary: dnf fails to verify gpgkey
Product: [Fedora] Fedora Reporter: Marcus Moeller <marcus.moeller>
Component: dnfAssignee: rpm-software-management
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 25CC: aliakc, jcdopsec, jmracek, jzeleny, marcus.moeller, matorola, mclay, mluscon, packaging-team-maint, patrick.pichon, redhat-bugzilla, rjones, sirdeiu, techtonik, tim.lauridsen, trurl7, vmojzis, vmukhame
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-25 18:24:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marcus Moeller 2015-05-26 07:51:45 UTC
I have added a repo definition like:

[isv_ownCloud_desktop]
name=The ownCloud Desktop Client (Fedora_21)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Fedora_21/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Fedora_21/repodata/repomd.xml.key
enabled=1

When trying to install a package from that repo (in this case owncloud-client), I got an error like:

warning: /var/cache/dnf/x86_64/22/isv_ownCloud_desktop/packages/libqtkeychain0-0.4-8.1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID ba684223: NOKEY
Traceback (most recent call last):
  File "/usr/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 185, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 141, in _main
    ret = resolving(cli, base)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 160, in resolving
    base.do_transaction()
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 216, in do_transaction
    self.gpgsigcheck(downloadpkgs)
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 249, in gpgsigcheck
    self.getKeyForPackage(po, fn)
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 1737, in getKeyForPackage
    keys = dnf.crypto.retrieve(keyurl, repo)
  File "/usr/lib/python2.7/site-packages/dnf/crypto.py", line 124, in retrieve
    keyinfos = rawkey2infos(handle)
  File "/usr/lib/python2.7/site-packages/dnf/crypto.py", line 107, in rawkey2infos
    ctx.import_(key_fo)
gpgme.GpgmeError: (7, 32870, u'Inappropriate ioctl for device')

In the past (when using yum), I have been prompted to accept the key in order to continue. This does not seem to happen anymore.

I have also tried to import the key manually in advance, using the rpm --import command, without a luck.

dnf-1.0.0-1.fc22.noarch is installed. Installing packages from the official repositories using gpgcheck seems to work, though.

Comment 1 Radek Holy 2015-05-26 09:04:38 UTC
Hi, I've hit similar problems when running DNF with a non-interactive standard input stream (i.e. mock --chroot). Can you confirm that this is your case?

Comment 2 Marcus Moeller 2015-05-26 09:19:58 UTC
Yes, that's also the case here. Sorry for not mentioning it initially.

Comment 3 Radek Holy 2015-06-03 13:52:54 UTC
*** Bug 1227689 has been marked as a duplicate of this bug. ***

Comment 4 Ali Akcaagac 2015-06-03 14:16:50 UTC
Yeah hit that one too. Quite irritating. Looks like yum is affected by this as well. At least the above marked duplicate bug has a reference to CementOS's yum.

Comment 5 Ali Akcaagac 2015-06-03 14:31:20 UTC
*** Bug 1226715 has been marked as a duplicate of this bug. ***

Comment 6 John 2015-09-11 16:05:47 UTC
Run into the same issue after installing the gitlab repo inside a CentOS 7 lxc container when working inside an lxc-attach session.

Curiously when I logged in to the same container through SSH magically everything worked fine. I was able to execute `yum search gitlab` without any errors. I was prompted to accept the keys as usual.

Comment 7 Richard W.M. Jones 2015-09-24 10:51:21 UTC
Same problem when running Fedora in a chroot on a phone.  Workaround is
to use dnf --nogpgcheck which is not nice.

Comment 8 Ali Akcaagac 2015-09-24 11:45:33 UTC
(In reply to Richard W.M. Jones from comment #7)
> Workaround is to use dnf --nogpgcheck which is not nice.

I initially thought myself that this may be a workaround. Unfortunately it isn't!

Reason:

If you work in a chroot (as I do) and you intend to install other repositories like RPMFUSION, GOOGLE, ORACLE, VIRTUALBOX and so on, then you migh possibly be installing some *.rpm packages that provide the key's as well as the *.repo files (this is of course optional in plenty of cases).

In case of RPMFUSION as example, the keys will not be installed into the RPM database if you use --nogpgcheck. You end up in package being installed. But the keys not added to the database.

I had to manually add the keys into the rpm database by running rpm -i key.

You can verify this by running:

rpm -qa | grep "^gpg-pubkey" | sort
gpg-pubkey-02e3ddfb-54f368d3
gpg-pubkey-34ec9cba-54e38751
gpg-pubkey-5ca6c469-548632d2
gpg-pubkey-6b6f9eec-54d3b43d
gpg-pubkey-6ce33d20-54d768b4
gpg-pubkey-7fac5991-4615767f
gpg-pubkey-873529b8-54e386ff
gpg-pubkey-8e1431d5-53bcbac7
gpg-pubkey-96ca6280-5544d430
gpg-pubkey-97f4d1c1-52ae28d3
gpg-pubkey-98ab5139-4bf2d0b0
gpg-pubkey-a29cb19c-53bcbba6
gpg-pubkey-a6708da3-52ae2b2e
gpg-pubkey-a8ce6fe9-54d38742
gpg-pubkey-b7546f06-5544d2dc
gpg-pubkey-e051b67e-54863278
gpg-pubkey-ff6382fa-3e1ab2ca

This is on my system. I believe I added rpmfusion, some copr keys and some other stuff manually to the rpm database.

Comment 9 Anatoly Pugachev 2015-12-31 11:10:46 UTC
if you're in chroot, try "mount /dev/pts" before command.

Comment 10 Ali Akcaagac 2015-12-31 11:29:20 UTC
(In reply to Anatoly Pugachev from comment #9)
> if you're in chroot, try "mount /dev/pts" before command.

Interesting! I will give this a definite try - but - I here on my system use mount -o bind /dev/ /chroot/dev. So the entire dev directory from the host is being binded to the other dev directory. This also includes the pts subdirectory. What I can do is trying an rbind rather than general bind and see whether there is a difference. Still - yum doesn't cause an issue like this.

Comment 11 Matt Clay 2016-01-06 07:33:16 UTC
I've encountered the same issue running inside an LXD container using lxc exec.

A simple work-around is to pipe the output of dnf through tee.

Running "dnf install -y -q which" fails with a stack trace and the error:

gpgme.GpgmeError: (7, 32870, u'Inappropriate ioctl for device')

While running "dnf install -y -q which | tee" succeeds.

Redirecting to /dev/null also works.

Comment 12 Ralf Ertzinger 2016-02-06 20:47:51 UTC
Bind mounting /dev will not pull in /dev/pts (at least on Fedora 23 it doesn't), you'll have to also bind mount that.

Comment 13 Ali Akcaagac 2016-02-06 21:51:56 UTC
(In reply to Ralf Ertzinger from comment #12)
> Bind mounting /dev will not pull in /dev/pts (at least on Fedora 23 it
> doesn't), you'll have to also bind mount that.

-bash-4.3$ mount --help | grep "rbind"
 <directory>             mountpoint for bind mounts (see --bind/rbind)
 -R, --rbind             mount a subtree and all submounts somewhere else
-bash-4.3$

Comment 14 Patrick Pichon 2016-06-22 09:59:56 UTC
Got the same problem on a fresh Fedora 24 installation !

rpm -qa | grep "^gpg-pubkey" | sort -> give nothing.

Comment 15 Fedora Admin XMLRPC Client 2016-07-08 09:31:28 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Fedora End Of Life 2016-07-19 14:15:21 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 17 Ali Akcaagac 2016-07-19 17:47:31 UTC
Could the owner of this bug please repopen this. The bug seem to be still existing and no other feedback has been given so far.

Comment 18 Jan Kurik 2016-07-26 05:01:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 19 techtonik 2016-07-27 08:52:44 UTC
It is still actual for 24.

Comment 20 Jaroslav Mracek 2017-05-12 17:01:33 UTC
We made a massive improvement of dnf in versions 2.4.1-1 that is available for rawhide and Fedora 26. We provide packages for Fedora 24+ from our testing repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly). Please can you test the case if it is still valid with dnf-2.4? Thanks a lot

Comment 21 Jaroslav Mracek 2017-05-25 18:24:03 UTC
I am sorry, but I am unable to reproduce a problem with dnf-2.4.1-1 that was released into rawhide and Fedora 26. Please if anyone will be able to reproduce the problem with dnf-2.4+, please reopen the bug report and we will be happy to fix it.

Comment 22 Ali Akcaagac 2017-05-27 07:23:56 UTC
Sorry for the delay in responding to this issue.

I confirm that this issue has been addressed in dnf 2.4.x (infact I am on 2.5.x now). From my initial tests, it looks like the issue with pgpgkey verification is indeed gone.

Thank you!

Comment 23 redhatted 2018-04-17 12:06:12 UTC
I can confirm that this is still happening on Fedora 27 with the VirtualBox repository:

$ sudo dnf update
Failed to synchronize cache for repo 'virtualbox', disabling.
Last metadata expiration check: 0:02:17 ago on Tue 17 Apr 2018 07:45:11 AM EDT.
Dependencies resolved.
Nothing to do.
Complete!

--verbose: 

Cannot download 'http://download.virtualbox.org/virtualbox/rpm/fedora/27/x86_64': repomd.xml GPG signature verification error: gpgme_op_verify() error: General error.
Failed to synchronize cache for repo 'virtualbox', disabling.