RPM 6.1.0 Ships With PKCS11 Package Signing and a New Kernel-Style Release Cadence

Overview

The RPM Package Manager project released RPM 6.1.0 on August 20, 2026, adding PKCS11 hardware-token signing to rpmsign and a new macro-modifier syntax, while serving as the first release under a version-numbering scheme the project modeled on the Linux kernel’s release cadence.

RPM is the packaging format and toolset underlying Fedora, Red Hat Enterprise Linux, openSUSE, and other major Linux distributions, making changes to its signing and build tooling relevant across a wide swath of the Linux ecosystem.

What We Know

• The headline security addition is hardware-backed package signing: according to the official 6.1.0 release notes, “rpmsign(1) can now sign files with PKCS11 tokens.”
• The release also introduces a new macro-modifier syntax for RPM’s macro processor. Per the release notes, “Macro behavior can now be altered by supplying modifiers at definition time. This new syntax consists of a list of arguments enclosed in < and >.”
• RPM 6.1.0 restores NSS-based user and group lookups by default, a behavior that had been disabled since RPM 4.19.0, according to the release notes.
• The release adds at least five new man pages — elfdeps(1), rpm-dependency-generators(7), rpm-design(7), rpm-scriptlets(7), and rpm-sysusers(7) — and expands the existing rpmbuild(1) and rpmkeys(8) pages, according to the release notes.
• Other changes in 6.1.0 include exporting the build script environment to an rpmbuild.env file, a new k stage argument for rpmbuild(1) to run the %check scriptlet independently, and a fix for verification output that had previously been excessive, misleading, or wrong in various scenarios, according to the release notes.
• RPM 6.1.0 is the first stable release under a versioning scheme the project announced in May. Under the new model, minor releases like 6.1 “[c]ontain new features and bugfixes” and “do not break things,” while micro releases are reserved for “security and bugfixes only, if needed between minor releases,” the project explained in a blog post on the release cycle.
• The project also shortened its pre-release process: minor releases will no longer go through a full alpha/beta cycle, instead getting “release candidates over a few weeks at most,” according to the same post.
• The project said the new cadence was, in its own words, “drawing some inspiration from the Linux kernel release model,” and explicitly contrasted it with the prior RPM 4.x series, which the post said “ran over two decades” with minor and micro version semantics that had been “less clear, to say the least,” according to the release-cycle post.
• RPM 6.1.0 followed two release candidates — one in May and one in July 2026 — before shipping as stable on August 20, 2026, per the project’s own release history. The GitHub release tag records the build as tagged on August 20 at 10:23 UTC. RPM 6.0.0, the prior major version, shipped in September 2025, according to the same release history.

What We Don’t Know

The release notes do not specify a timeline for when downstream distributions such as Fedora or openSUSE Tumbleweed will adopt RPM 6.1.0, nor do they quantify how many packages or environments rely on the previously restored NSS-based lookup behavior.

Analysis

The versioning overhaul is arguably the more consequential change for the broader ecosystem than any single feature in 6.1.0. By committing to a predictable, kernel-style cadence — minor releases on a regular schedule, short release-candidate windows, and micro releases reserved strictly for fixes — the RPM project is signaling an end to the ambiguity that characterized the four-x series, where the same numbering scheme covered two decades of releases with inconsistent compatibility guarantees. For distribution maintainers who build release schedules around upstream tooling, a documented and shortened RC cycle is a planning benefit independent of what any given release contains.