The jump to RPM 6.0 marks a before and after in the most widespread package manager in the ecosystem of Red Hat Enterprise Linux, SUSE, and derivatives. This release combines years of work to modernize security, package formats, and tools, and it's evident in every corner of the project. If you manage systems or package software, this change is important to you because it affects how you build, sign, verify, and install packages.
The release was made on September 22, 2025, and follows a candidate that has finally been confirmed as the final version. In addition to the public announcement, there is a major effort in documentation and default behavior changes. RPM 6.0 Introduces support for the new v6 format and strengthens cryptographic verification, while maintaining support for v4 packages and eliminating the installation of v3.
What is RPM 6.0 and why it matters
With RPM 6.0, the project consolidates more secure signing practices, deprecates outdated algorithms, and paves the way for a package format ready for modern sizes and metadata. The v4 format turns 25 and the codebase is approaching its 30th anniversary., so this major revision was necessary to bring it up to current standards and the size of contemporary repositories.
The official announcement highlights milestones such as OpenPGP multi-signature management, support for OpenPGP v6 keys and signatures (including post-quantum cryptography), and the adoption of strategies for obtaining pristine and verifiable release tarballs. The main goal is to raise the bar on security without breaking compatibility. in the daily life of packers and administrators.
Downloads and footprints
The distribution includes the main source file rpm-6.0.0.tar.bz2, accompanied by its SHA256 checksum for integrity checking. SHA256: 14abb1b944476788d90005d8d61d5d30fce80d9f0de11eb657b14e5c9ef27441.
Overview of changes compared to 4.20.1
- Support for v4 and v6 packages, with detailed compatibility notes.
- Multiple OpenPGP signatures per packet and support for OpenPGP v6 and PQC keys.
- Updating previously imported keys and using the full fingerprint or ID throughout the cycle.
- The v3 package installer is being retired; they can be viewed and extracted with rpm2cpio, but not installed.
- Strict enforcement of signature verification by default, increasing ecosystem security.
- Major revision of man pages and documentation, with versioned content on the official website.
- Pristine and verifiable release tarballs, strengthening reproducibility and auditing.
Changes and improvements for general use
The rpmkeys utility gains a lot of weight in key management: Now allows updating keys with rpmkeys –import (including updating the ambiguous short identifier to a full fingerprint), import from a pipe, export with rpmkeys –export, and operate consistently across different keychain backends. Additionally, with rpmkeys –rebuild, keychain contents can be rebuilt and migrated between backends, and key lookups are now case-insensitive.
rpmsign also makes a jump: It can be signed with GnuPG or Sequoia-sq controlled with the %_openpgp_sign macro. The rpmsign –addsign subcommand no longer replaces existing signatures; by default, it adds any number of signatures to v6 packages, and also to v4 packages if –rpmv6 is used. RPMsign –resign, on the other hand, replaces all previous signatures with a new one.
For queries, tag extensions such as rpmformat (find out if it's v3, v4, or v6) and openpgp (management of all OpenPGP signatures) are added. The :hashalgo formatter is added to display hash algorithm names, and the alias –filemime appears to query the MIME by file. Terminology is standardized across messages: OpenPGP is used consistently, and v3 header and payload signatures are labeled as legacy.
New calculation function and bug fixes in RPM 6.0
A new feature calculates a configurable set of summaries during verification and saves them to the RPM database, helping to identify the source package file. Multiple operational issues resolvedScriptlet errors now affect transaction result codes; certain failed triggers impact related operations; and issues with –hash, –percent, and –test in conjunction with –restore have been fixed.
Bugs such as a segfault and leaks in rpmgraph, the suffix used by rpm2archive for tar and cpio, are fixed, and a major rewrite of the man pages is undertaken: Uniform style with examples, new pages for components and formats, relocating user commands to section 1, and covering previously undocumented aspects. The versioned documentation on the official website includes man pages, a reference manual, and an API.
Packaging and package construction
rpmbuild can now generate two different formats controlled by the %_rpmformat macro (values ​​6 or 4). In addition, self-signing is enabled in the build If %_openpgp_autosign_id is defined, and the rpm-setup-autosign tool is added to facilitate that configuration.
In macros, %{span:…} is added to facilitate multi-line definitions and %{xdg:…} is added to evaluate XDG base paths. Support for E2K architecture is added and a battery of fixes: source order and patches in the header, Lua glob respecting the c argument, architecture validation at the correct point, acceptance of build system-specific %prep sections, and fixes in check-rpaths when RPATH and RUNPATH coexist.
Fixes a memory leak in rpmspec –shell, a 4.20 regression in rpmbuild -rs with non-existent directories, and an extra newline in rpm –eval. A segfault is also fixed. in the event of invalid output from the dependency builder in multi mode, and the brp-selfperms policy has been removed. Finally, the deprecated –nodirtokens switch from rpmbuild has been removed.
API Changes
In the keychain area, functions are added to iterate and manage keys: rpmKeyringInitIterator, rpmKeyringIteratorNext, rpmKeyringIteratorFree, rpmKeyringVerifySig2, rpmKeyringLookupKey and rpmKeyringModifyFor rpmPubkey, accessors such as rpmPubkeyFingperint, rpmPubkeyFingerprintAsHex, rpmPubkeyKeyIDAsHex, and rpmPubkeyArmorWrap are added, as well as rpmPubkeyMerge to merge descriptors of the same key.
For the permanent transaction keychain, rpmtxnImportPubkey, rpmtxnDeletePubkey, and rpmtxnRebuildKeystore are included. The rpmSign operation is controlled with new flags: RPMSIGN_FLAG_RESIGN, RPMSIGN_FLAG_RPMV4, and RPMSIGN_FLAG_RPMV6. rpmteVfyLevel and rpmteSetVfyLevel, along with their equivalents te.VfyLevel and te.SetVfyLevel, have also been added to the Python bindings.
For multiple signatures, identifiers such as RPMTAG_OPENPGP, RPMSIGTAG_OPENPGP (alias of the above) and the verification flag RPMVSF_NOOPENPGP appear. New labels are added: RPMTAG_PAYLOADSIZE, RPMTAG_PAYLOADSIZEALT, RPMTAG_RPMFORMAT, RPMTAG_FILEMIMEINDEX, RPMTAG_MIMEDICT, RPMTAG_FILEMIMES, RPMTAG_SOURCENEVR, RPMTAG_PAYLOADSHA512, RPMTAG_PAYLOADSHA512ALT, RPMTAG_PAYLOADSHA3_256, RPMTAG_PAYLOADSHA3_256ALT, RPMTAG_SHA3_256HEADER.
There are renamed tags: RPMTAG_PAYLOADDIGEST is moved to RPMTAG_PAYLOADSHA256, RPMTAG_PAYLOADDIGESTALT is moved to RPMTAG_PAYLOADSHA256ALT, and RPMTAG_PAYLOADDIGESTALGO is marked as deprecated under RPMTAG_PAYLOADSHA256ALGO. SHA-3 identifiers are added: RPM_HASH_SHA3_256 and RPM_HASH_SHA3_512, as well as per-file MIME-related symbols in v6 packages, such as rpmfilesFMime and rpmfiFMime, and the RPMFI_NOFILEMIME flag.
In the OpenPGP domain, RFC 9580 compliant identifiers and the pgpDigParamsSalt function are added to retrieve the pre-salt of v6 signatures. For digest bundles, rpmDigestBundleUpdateID appears. (updates individual identifiers). Other new features: rpmtsAddInstallElement returns 3 for unsupported formats, and fdSize reports an error for non-regular files.
Internal improvements
RPM code is moved to C++20 (except for Python plugins and bindings). Fonts are renamed to .cc and .hh, dynamic structures are migrated to STL, and reference counting is reinforced with atomic operations. In addition, the test suite is expanded and test creation is simplified.
A real keychain abstraction and an experimental backend based on openpgp.cert.d are introduced. Added build make site target to render local documentation, and the test image adapts to the toolbox. Underscores are allowed in RPMTAG names, and regressions have been fixed, such as the reserved size for signatures and the alternatives mechanism interfering with signatures.
Fixed keychain reads without transaction locking, a race condition in rpmioMkpath, recursion depth in macro error messages, and a case where empty passwd or group fields caused entries to be ignored. Internal macros are available again before loading files, the fdSize error in rpmSign is handled correctly, pseudo-tags are cleaned up in –querytags, and the installation prefix is ​​respected in the legacy find-provides and find-requires scripts.
Other internal improvements
Also fixed are file-related reference leaks in Python, dependency storage is stabilized to avoid nondeterminism, chroot escaping in the sysusers script with u! entries is fixed, and a 4.19 regression in failed update return codes is fixed. Warning about macrofiles in rpmrc, the transaction lock is recreated after –rebuilddb, provides gpg(keyid) is removed from gpg-pubkey, and symbols that were accidentally leaked to the ABI are cleaned up.
Non-portable uses of signal have been removed, rpmlog locking has been optimized, and Python bindings support module isolation for multiple subinterpreters and fix resource leaks with ASAN testing. They are improvements that improve robustness, portability and maintainability. on all fronts.
Requirements for compiling RPM
A C++20 compiler is now required in addition to C99; C++20 module support is not required. To build with Sequoia, rpm-sequoia 1.9.0 or higher is required (and is the default option), Python 3.10 or higher for bindings, and the scdoc generator for man pages.
Precompiled API documentation is no longer included in release tarballs; building it is optional with Doxygen. Pre-built APIs per version are available in the project's FTP.
RPM 6.0 Compatibility and Format Keynotes
The v6 packet format brings 64-bit file size and related limits, cryptographic modernization with the removal of MD5 and SHA1, SHA3-256 hashes in the header, and SHA512 and SHA3-256 digests in the payload. MIME information is added per file, and there's broad support for RPM starting with 4.14 (with nuances). External dependency generator mode is no longer supported in v6, and legacy rpmlib dependencies prior to 4.6 have been removed to clean up noise.
v6 packages can be checked out with RPM from 4.6, unpacked with 4.12, and verified and installed with 4.14 or higher, subject to known limitations. v4 packages remain fully supported and those generated by 6.0 are identical to those of the 4.x branch; however, under the default configuration, packages built with RPMs lower than 4.14 are not verified because they use weak digests. You can set %_pkgverify_level to signature to ignore these digests, or restore 4.x behavior by setting %_pkgverify_flags to 0 if weak digest verification is required.
The v3 installation is removed, although it can be viewed and extracted with rpm2cpio. By default, RPM builds v6 packages; this can be reverted by setting %_rpmformat to 4. In packages built with RPM 6.0 or higher, the posix.fork Lua family is disabled, while in packages built with 4.20 or earlier it continues to work.
Other considerations: the signing key configuration is now defined with %_openpgp_sign_id (backwards compatibility with %_gpg_name), low-level signing macros become parametric, and custom %__gpg_sign_cmd overrides no longer work out-of-the-box. %_passwd_path and %_group_path are allowed to be colon-separated lists. to use multiple NSS sources, and the –pkgid and –hdrid query switches are removed.
RPM 6.0 and Fedora 43: Scope, Benefits, and Testing
The upgrade to RPM 6.0 in Fedora 43 It seeks to strengthen security and prepare the ground for the v6 format, but without yet adopting the new format as the default. Fedora 43 will continue to generate v4 by default., and strict enforcement of signature verification will be addressed as a system change in a future release.
Key benefits for Fedora include: OpenPGP keys are now always identified by fingerprint or full ID, they can be updated with rpmkeys –import, multiple signatures per package are supported, local self-signing is supported during builds, and the use of Sequoia-sq as an alternative to GnuPG. It also makes it easier to test the v6 format in the ecosystem without forcing its global adoption.
Not in scope: general migration of Fedora to v6 format or changing the default verification mode. Changemakers are responsible for exceeding RPM and assist with incompatibilities, while the rest of the developers must test, report problems, and adapt third-party tools when necessary.
Upgrade and Compatibility Impact: Third-party scripts and tools may require adjustments due to the new key address format and signature-related output changes. For early testing It is advisable to validate: updating imported keys, keychain management with rpmkeys, and compatibility of the v6 format with external software (building with %_rpmformat to 6).
RPM 6.0 User Experience on Fedora
User Experience: Signature and key output is standardized to uppercase and lowercase, and keys are displayed by fingerprint or full ID, abandoning the old collision-prone short ID. rpmkeys is established as an official tool to manipulate the keychain; old methods such as manually touching gpg-pubkey pseudo-packages are deprecated and should be migrated to rpmkeys or the new APIs.
Dependencies: The SOName doesn't change, so no dependency rebuilds are required; there are no dependencies on other Fedora changes. RPM is built as C++, so it adds a runtime dependency on libstdc++. Signing with Sequoia requires sequoia-sq 1.0 or higher as an optional dependency and only affects package signing.
Contingency plan: revert to RPM 4.20 if necessary, with a deadline of the beta freeze, without blocking the release. Delivery continues even though v6 format is not yet the default in distribution.
RPM 6.0 Release Notes and Background Announcement
The previous candidate incorporated bug fixes and man page updates, and was promoted to final. The announcement signed by the RPM team It highlights that work has been done towards this milestone since the rpm.org restart around 2007, with milestones such as 64-bit file sizes, pluggable dependency generators, transaction plugins, rich dependencies, file triggers, debuginfo improvements, new database backends, Lua integration and macro expressions, dynamic build-requires, spec generation, user and group support, and declarative build systems.
Over 300 people have contributed code from multiple distributions and organizations. The history of the project and its community explain the stability and scope that RPM 6.0 inherits and expands.
The outlook for RPM 6.0 is that of a strengthened package manager for the next decade: Better cryptography, high-volume format, more powerful tools, and up-to-date documentation., with a clear compatibility path for administrators, packagers, and ecosystems to adopt new features without any issues.
