Red Hat Bugzilla – Bug 1311258
doc: localpkg_gpgcheck not mentioned in man dnf.conf
Last modified: 2016-07-19 14:44:29 EDT
Description of problem:
localpkg_gpgcheck is not mentioned in dnf.conf manpage but seems to be accepted by dnf.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
man dnf.conf |grep localpkg_gpgcheck
should show something
Just recently, we have open a discussion about usefulness of gpg-check of local rpm, but we still haven't come to final decision. We are still unsure if localpkg_gpgcheck or default behavior with gpg check for local rpm is useful for users. Probably if you will present us some interesting user case, we can come directly with decision.
There is also more common solution of secure package distribution - repository. It allows not only gpg-key check but also checksum check to prevent installation of corrupted packages.
Anyway, thank you in interest in DNF.
For me as a security-conscious person, I would like to have gpg checks enabled by default and would like DNF to ask me when I would install unsigned RPMS. I mainly need to be able to install unsigned RPMs if I built them locally or when I downloaded unpushed updates from kojipkgs via https. However, if I need to install RPMS from an untrusted source like a mirror, I would like dnf to verify the signature. This is for example needed if I want to install the RPMS downloaded by some other tool (yum or packagekit), since all the package managers on Fedora do not share the same package cache. If packagekit already donwloaded a bunch of updates I would like to be able to install them from their cache if I do not have access to a fast internet connection. Also when sharing RPMS with other people in these situations, I would like dnf to verify the signature. Nevertheless, especially for other security-conscious people that I want to get into using Fedora it would be good if DNFs behaviour regarding unsigned RPMS would be more transparent.
we'll try to test it and document.
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
Thank you for reporting this bug and we are sorry it could not be fixed.