Description of problem: I have one repository that is using repo_gpgcheck=1. Whenever I use dnf --cacheonly (as a user), dnf wants to import the GPG key for this repository. (The GPG key has been imported as root before.) As this obviously does not work, the repository is disabled and thus not available for --cacheonly operations: Cache-only enabled but no cache for 'xyz', disabling. This is apparently due to the fact that /var/cache/dnf/x86_64/22/xyz/pubring/trustdb.gpg is not world-readable and can thus not be accessed as a non-root user. Version-Release number of selected component (if applicable): dnf.noarch 1.0.1-2.fc22 dnf-conf.noarch 1.0.1-2.fc22 dnf-yum.noarch 1.0.1-2.fc22 python-dnf.noarch 1.0.1-2.fc22 python3-dnf.noarch 1.0.1-2.fc22 How reproducible: Always when using --cacheonly as a user Steps to Reproduce: 1. Install a repository using repo_gpgcheck=1 2. dnf --cacheonly list installed '*dnf*' Actual results: dnf prompts to import GPG key. Expected results: dnf does not prompt and uses the repository.
we should change the permissions of gpg key to be readable by user.
still true for f24
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.
I think we have here little bit different problem. Repo_gpg key is different that rpm gpg key. It is imported into cache directory with metadata. But user use different cache than root (for good security reason), therefore also import of gpg key is in different place. If we will allow to share gpg key location for users and root we will have to answer question who has rights to write down the gpg key? And what happen when key is changed? If user will not have rights he will be unable to use repo's gpg verification. From my point of view it is not a bug because if you import repo gpg key into cache it is valid for user that imported it and the logic is same like for metadata.
See bug 1350930, where enabling fedora-cisco-openh264, shipped in the fedora-repos package, makes fedora-review stop working due to this issue. The messages generated by dnf are not helpful in figuring out why fedora-review has stopped working. Even if this is not a bug, the messages could be improved to help packagers figure out the real nature of the problem.
Probably we can think to use rpm database of imported gpgkeys, but for other reason keep present behavior. But I have to ask people from RPM, if there is any API that could provide us information about imported gpgkeys. Thanks in advance to RPM team for any information.
*** Bug 1398868 has been marked as a duplicate of this bug. ***
*** Bug 1416103 has been marked as a duplicate of this bug. ***
There is the rpmKeyring API found in rpmio/rpmkeyring.h (or include/rpm/rpmkeyring.h). It is also available in Python as the keyring class and the ts.getKeyring() method (or rpmtsGetKeyring() in C).
Hello, could somebody please look into this? This is blocking BZ #1350930, so me and others are currently workarounding this when doing fedora-review. This is really pain in the a** for many people. Thank you!
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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.
iirc it is still a problem in at least Fedora 25
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This issue is still present in rawhide with dnf-4.2.7-1.fc31 and libdnf-0.35.1-1.fc31, changing version to 'rawhide' again.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
*** Bug 1655202 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Not sure if there is an intent to resolve this or not but I will add my notes and workarounds in case it is of use. Related post on reddit: https://www.reddit.com/r/Fedora/comments/mmhfne/help_dnf_keeps_prompting_about_importing_gpg_key/ --------------- Notes: --------------- I ran into this issue under Fedora 33 (Cinnamon) after installing teamviewer via the rpm package (a signing key was added automatically but only for the root account). Later usage of query-type commands run from non-root accounts such as with `dnf search neofetch` or `dnf list installed neofetch` would trigger a prompt for that non-root user to import a GPG key. Typing "Y" to allow its download would allow the command to continue for that one iteration but the prompt would reappear again later after the meta fresh cache expired. Manually attempting to import the key from the non-root account resulted in an error. Initially, I had also been getting similar errors after installing asbru-connection-manager (multi-tabbed ssh connection manager) using curl -1sLf 'https://dl.cloudsmith.io/public/asbru-cm/release/cfg/setup/bash.rpm.sh' | sudo -E bash; sudo dnf install -y asbru-cm; but the import prompts related to asbru seemed to go away after running the following to fix some inconsistent permissions cached files/folders: sudo find /var/cache/dnf -type d -iregex '.*asbru.*' -not \( -perm /o+r -perm /o+x -perm /g+r -perm /g+x \) -exec chmod 755 "{}" \;; sudo find /var/cache/dnf -type f -iregex '.*asbru.*' -not \( -perm /o+r -perm /g+r \) -exec chmod 644 "{}" \;; running similar commands for teamviewer: sudo find /var/cache/dnf -type d -iregex '.*teamviewer.*' -not \( -perm /o+r -perm /o+x -perm /g+r -perm /g+x \) -exec chmod 755 "{}" \;; sudo find /var/cache/dnf -type f -iregex '.*teamviewer.*' -not \( -perm /o+r -perm /g+r \) -exec chmod 644 "{}" \;; only resolved the issue temporarily until the next cache refresh. My personal opinion is that the prompt is undesirable when running as non-root but there may be other use-cases that I am unaware of. Based on my testing, the prompt appeared for the following (query-based) dnf command verbs run from non-root: check-update, deplist, info, list, provides, repoquery, search, updateinfo I did not test commands intended for modifying the system such as install/remove as I assume these would only ever be run from the root account. ------------------------------ Workarounds: ------------------------------ The flag `--nogpgcheck` seems to be the main way to avoid this prompt and is particularly useful for scenarios where a non-root script must use dnf to run a query such as via seach/deplist/info/list/repoquery/etc commands. I had this happen previously in a script and it had hung due to the prompt. Outside of scripts, the main workarounds I have found for non-root users are to either create user aliases in ~/.bash_aliases or similar such as `alias dnfs='dnf search --nogpgcheck --cacheonly --assumeno --quiet'` or `alias dnfs='dnf search --nogpgcheck --assumeno --quiet'`. Or to create dnf command aliases from the root account which will override all of the dnf query type commands where the prompt can appear for non-root users. e.g. `sudo dnf alias add provides="\provides --nogpgcheck --cacheonly --assumeno --quiet"` In my case, I felt that results with --cacheonly for many of these commands would be "good enough" but some users may want to review if this is appropriate for their intended usage of certain commands like search, list, etc. The contents of my /etc/dnf/aliases.d/USER.conf are as follows: root@fedora:/etc/dnf/aliases.d# ls -acl total 4.0K -rw-r--r--. 1 root root 1.3K Apr 9 17:13 USER.conf root@fedora:/etc/dnf/aliases.d# cat USER.conf [main] enabled = True [aliases] check-update = \check-update --nogpgcheck --assumeno --quiet check-upgrade = \check-update --nogpgcheck --assumeno --quiet deplist = \deplist --nogpgcheck --cacheonly --assumeno --quiet info = \info --nogpgcheck --cacheonly --assumeno --quiet info-sec = \updateinfo --nogpgcheck --assumeno --quiet info-security = \updateinfo --nogpgcheck --assumeno --quiet info-updateinfo = \updateinfo --nogpgcheck --assumeno --quiet list = \list --nogpgcheck --cacheonly --assumeno --quiet list-sec = \updateinfo --nogpgcheck --assumeno --quiet list-security = \updateinfo --nogpgcheck --assumeno --quiet list-updateinfo = \updateinfo --nogpgcheck --assumeno --quiet ls = \list --nogpgcheck --cacheonly --assumeno --quiet provides = \provides --nogpgcheck --cacheonly --assumeno --quiet prov = \provides --nogpgcheck --cacheonly --assumeno --quiet repoquery = \repoquery --nogpgcheck --cacheonly --assumeno --quiet rq = \repoquery --nogpgcheck --cacheonly --assumeno --quiet se = \search --nogpgcheck --cacheonly --assumeno --quiet search = \search --nogpgcheck --cacheonly --assumeno --quiet summary-updateinfo = \updateinfo --nogpgcheck --assumeno --quiet updateinfo = \updateinfo --nogpgcheck --assumeno --quiet whatprovides = \provides --nogpgcheck --cacheonly --assumeno --quiet
oops.. forgot to include teamviewer's repo config. This is this mine (I did not make any customizations so it should be as configured by their rpm file): $ cat /etc/yum.repos.d/teamviewer.repo [teamviewer] name=TeamViewer - $basearch baseurl=https://linux.teamviewer.com/yum/stable/main/binary-$basearch/ gpgkey=https://linux.teamviewer.com/pubkey/currentkey.asc gpgcheck=1 repo_gpgcheck=1 enabled=1 type=rpm-md failovermethod=priority
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 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. Thank you for reporting this bug and we are sorry it could not be fixed.