RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1929728 - DNF handles repo_gpgcheck=1 oddly.
Summary: DNF handles repo_gpgcheck=1 oddly.
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf
Version: 8.3
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: swm-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-17 14:05 UTC by Pat Riehecky
Modified: 2022-03-15 14:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-15 14:07:27 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CentOS 18068 0 None None None 2021-02-17 14:05:05 UTC

Description Pat Riehecky 2021-02-17 14:05:06 UTC
Description of problem:

DNF handles repo_gpgcheck=1 oddly.

DNF should use GPG for key management. GPG is designed for the task.
DNF repo_gpgcheck should check the signature against keys in the user's keyring, or in a system keyring.
DNF currently manages keys itself, and does so in ways that are arguably unsafe.


I see 3 issues with the current behavior:
1. dnf stores a separate copy of the key for each repo in the cache
2. dnf -y update will add keys without prompting the user
3. clearing the dnf cache drops the keys, exposing the system to?

Version-Release number of selected component (if applicable):4.4.2-2.el8


How reproducible: always


STEPS TO REPRODUCE (USE CASE 1)
### Note that in this example, all four repos are signed with the same key.
### All commands are run as root in this example.
# dnf config-manager --save --setopt=*.repo_gpgcheck=1 appstream baseos extras powertools
# dnf update
## RESULT: Operator is asked to accept the key 4 times, waiting for each repo to load.
## RESULT: This wastes operator time and makes automation difficult


STEPS TO REPRODUCE (USE CASE 2)
### Clear the cache for this test
# rm -Rf /var/cache/dnf/* /var/cache/dnf/.gpgkeyschecked.yum
# dnf config-manager --save --setopt=*.repo_gpgcheck=1 appstream baseos extras powertools
# dnf -y update
## RESULT: DNF accepts the keys without prompting


STEPS TO REPRODUCE (USE CASE 3)
### Set up the test
# rm -Rf /var/cache/dnf/* /var/cache/dnf/.gpgkeyschecked.yum
# dnf config-manager --save --setopt=*.repo_gpgcheck=1 appstream baseos extras powertools
# dnf -y update
### Demonstrate that dnf has the keys (should not prompt the user):
# dnf update
### The real test starts here. An operator has deleted the cache for some reason.
# rm -Rf /var/cache/dnf/*
# dnf update
## RESULT: DNF prompts the user to accept the same key 4 times.

Actual results:
keys are stored in raw files rather than a system keyring

Expected results:
keys stored in a system keyring

Additional info:
dnf stores the gpg keys under /var/cache/dnf, for example:
 /var/cache/dnf/extras-2770d521ba03e231/pubring/trustdb.gpg
 /var/cache/dnf/powertools-25a6a2b331e53e98/pubring/trustdb.gpg
 /var/cache/dnf/baseos-929b586ef1f72f69/pubring/trustdb.gpg
 /var/cache/dnf/appstream-a520ed22b0a8a736/pubring/trustdb.gpg

Comment 2 Phil Perry 2021-05-09 18:04:05 UTC
Related to https://bugzilla.redhat.com/show_bug.cgi?id=1768206

Comment 3 Jaroslav Mracek 2022-03-15 14:07:27 UTC
It looks like a complicated issue to solve. Also the change of behavior is difficult during RHEL8 livecycle therefore I am closing it. We will revisit the issue during preparation of behavior of main packager in RHEL10.


Note You need to log in before you can comment on or make changes to this bug.