Description of problem: DNF has no public api methods for handling gpg signature check on packages and fetch keys and asking the user for confirmation for installing the keys. USECASE: In a graphical package manager like yumex-dnf it should be possible to ask the user to import a gpg key from the path defined in the .repo file. this is currently only possible by using non public API dnf.Base._sig_check_pkg() dnf.Base._get_key_for_package(fullcb=custom_callback) It proberly not a good idea to make these method public API but some way of doing gpg signature check of a list of downloaded packages with a custom callback to handle the confirmation of gpg key installation. Version-Release number of selected component (if applicable): 1.1.9
We will design more convenient return codes of `sig_check_pkg` and add it into API.
Thanks
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Any update on this?
This is still not in planned to be implemented for the next quarter. Sandro, may I ask you in which app do you want to use requested feature so we can raise reconsider it's priority?
(In reply to Honza Silhan from comment #5) > This is still not in planned to be implemented for the next quarter. > > Sandro, may I ask you in which app do you want to use requested feature so > we can raise reconsider it's priority? The code that we want to use this in is 'otopi', which is used (also) in engine-setup - the tool used to upgrade ovirt-engine. We used to do this, and dropped the call once it was removed from dnf, see also bug 1343382 (to remove the call) and bug 1344270 (to add it, once you expose something in current bug).
Any plan to prioritize this?
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.
Didn't verify but am pretty certain that it's not fixed yet.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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.
(In reply to Yedidyah Bar David from comment #9) > Didn't verify but am pretty certain that it's not fixed yet. Still. Aren't any other users of dnf in need if this bug? Only oVirt? Other users: Please add comments and/or "Blocks:". Thanks. DNF maintainers: I do not think this is a hard bug to fix, it's as simple as making _sig_check_pkg public again. If there was a deep reason to hide it, perhaps at least document it here, so that we know why it takes so long. Moving to 28 for now, marking high severity.
So far no prediction from our side.
Can you expose back _sig_check_pkg for the time being, until you have a decision about future behavior? Thanks!
We have prioritized this work into our current backlog. New code will be written in libdnf, exported via SWIG to Python and provided in DNF as a public API.
* _sig_check_pkg() is now exposed as base.package_signature_check() API method * _get_key_for_package() is now exposed as base.package_import_key() API method
I believe that bug request is delivered therefore closing the bug report.