Fedora developers have proposed a system-wide change for Fedora 44 that would enforce RPM package signature verification by default to tighten security in the software supply chain. While Fedora and DNF have long required signature verification for repositories, RPM itself has historically treated unsigned packages as valid.
If accepted, the change would make Fedora follow the upstream RPM 6.0 defaults, which allow only packages with verified cryptographic signatures to be installed. In practice, this means users won’t be able to install unsigned RPMs unless they explicitly override the verification process with the --nosignature flag or a corresponding API call.
As proposal author Panu Matilainen from Red Hat explains:
“The traditional RPM <= 4.x behavior was to verify a signatures if they are present and verifiable, but never require it. That behavior may have been somehow acceptable in the nineties, but does not meet the security expectations of modern times.”
The Fedora team notes that the DNF5 package manager (version 5.2.14 or later) already includes per-package signature disabling. This allows tools like mock and COPR to continue building and testing unsigned packages without breaking workflows.
Moreover, locally built packages using rpmbuild will also be easier to sign automatically, thanks to new RPM 6.0 support for passwordless key signing via a setup script (/usr/lib/rpm/rpm-setup-autosign).
For most Fedora users, the change should have no noticeable impact. Official repositories and COPR builds already use signed packages. However, developers who rely on unsigned local packages may need to adjust workflows — either by signing their builds or using explicit overrides.
The proposal will undergo public feedback before being reviewed by the Fedora Engineering Steering Committee (FESCo), a key governing body within the Fedora Project that oversees various technical decisions related to the distro’s development. If approved, the change will land in Fedora 44, expected next spring. Otherwise, it could be postponed to a future release, such as Fedora 45.
For more information, see the proposal itself.
