Bug 1224908
Summary: | dnf fails to verify gpgkey | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marcus Moeller <marcus.moeller> |
Component: | dnf | Assignee: | rpm-software-management |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 25 | CC: | 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
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? Yes, that's also the case here. Sorry for not mentioning it initially. *** Bug 1227689 has been marked as a duplicate of this bug. *** 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. *** Bug 1226715 has been marked as a duplicate of this bug. *** 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. Same problem when running Fedora in a chroot on a phone. Workaround is to use dnf --nogpgcheck which is not nice. (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. if you're in chroot, try "mount /dev/pts" before command. (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. 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. 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. (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$ Got the same problem on a fresh Fedora 24 installation ! rpm -qa | grep "^gpg-pubkey" | sort -> give nothing. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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. 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. This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'. It is still actual for 24. 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 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. 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! 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. |