Bug 1929728 - DNF handles repo_gpgcheck=1 oddly.
Summary: DNF handles repo_gpgcheck=1 oddly.
Keywords:
Status: NEW
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: 2021-02-22 12:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


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


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