Not unless the repo file asks them to. According to the DNF configuration reference, gpgcheck, repo_gpgcheck and localpkg_gpgcheck all default to false. If you ship an RPM repository, sign the packages and the metadata, and ship a repo file that turns the checks on and names your key.
Definitions
Three options control signature checks.
| Option | Checks | Default |
|---|---|---|
| gpgcheck | Signatures on packages from the repository | False |
| repo_gpgcheck | Signatures on the repository metadata | False |
| localpkg_gpgcheck | Signatures on package files installed from a local file | False |
The gpgkey option lists URLs of key files DNF can use to verify packages and metadata. It is empty by default. If a file cannot be verified with keys already imported, DNF tries to import the keys listed there.
The reference also notes that gpgcheck can only strengthen the active RPM security policy. If the policy macro for package verification is set to require signatures and gpgcheck is false, DNF overrides it to true at runtime and prints a warning.
Why vendors should care
Package signing tells the customer the RPM came from you. Metadata signing tells them the list of packages and versions came from you. Without the metadata check, an attacker who controls a mirror could serve old signed packages with a metadata file that hides a fix. Signing both closes more of the gap.
Steps for a vendor
- Create a dedicated release signing key, kept off build workers, ideally in a hardware or managed key service.
- Sign every RPM before it enters the repository.
- Sign the repository metadata.
- Publish a repo file with gpgcheck and repo_gpgcheck set to 1 and a gpgkey URL on an HTTPS page you control.
- Publish the key fingerprint in your docs, so customers can compare it with what they import.
- Tell customers that repo_gpgcheck keys are stored separately from package keys and per repository, so DNF may ask them to import the same key more than once. That prompt is expected.
Customers installing a single downloaded RPM
Customers who download one file and install it directly rely on localpkg_gpgcheck. Document the key import and the verify command in your install guide, and publish a checksum too. See checksum versus signature for when each helps.
Key rotation
Plan the day you replace the key. Publish the new key alongside the old one, overlap for a defined period, and announce the date in your advisory list. A customer whose repo file lists only the old key will see failures after the switch.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Is signing the packages enough?
It is a start. Signing the metadata as well covers the package list and versions, which package signatures alone do not.
Why does DNF ask to import the key twice?
Keys for metadata checks are stored separately from package keys and separately for each repository, per the DNF reference.
Sources
Last reviewed: 19 October 2026.
