F43 Change Proposal RPM 6.0 (system-wide)

Project Discussion Change Proposals
,
1

RPM 6.0

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Update RPM to the upcoming 6.0 major release.

:link: Owner

:link: Detailed Description

Update RPM to the upcoming 6.0 release for several security improvements.

Note: adopting Fedora to the new v6 package package format is explicitly NOT IN SCOPE for this change. RPM 6.0 in Fedora 43 will ship with v4 package generation as default, regardless of the upstream default.

:link: Feedback

:link: Benefit to Fedora

The major theme in 6.0 is increased security and related improvements:

  • enforcing signature checking on by default
  • OpenPGP keys are referred to by their fingerprint or full key id where fingerprint not available (compared to the short keyid in previous versions)
  • OpenPGP keys can be updated with rpmkeys --import <key> and corresponding API(s)
  • support for multiple signatures per package (also an enabler for Post-Quantum signatures later on)
  • support for automatic signing on package build (mainly for local use)
  • support for signing with Sequoia-sq as an alternative to GnuPG

A less direct benefit is enabling the testing of the new v6 package format in the wider ecosystem.

Last but not least: with the release of 6.0, the RPM 4.x branch will go into a strict maintenance-only mode, there will be no further development on that branch.

:link: Scope

This is the first RPM version to support the new v6 package format, but adopting Fedora to the new package format is explicitly not in scope for this change.

  • Proposal owners:

    • Rebase RPM
    • Assist dealing with incompatibilities

  • Other developers:

    • Test and report issues
    • Adjust 3rd party software/tools to work with the new formats and defaults where needed
    • Test v6 package behavior with 3rd party software/tools (optional)

  • Release engineering: #12616

  • Policies and guidelines: N/A

  • Trademark approval: N/A

  • Alignment with the Fedora Strategy: N/A

:link: Upgrade/compatibility impact

  • Existing package build+install workflows may need to be adjusted due to enforced signature checking being the default.
  • 3rd party scripts and tools may need adjusting to the new key addressing format and other signature related output changes.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

Rpm receives a thorough and constant testing via every single package build, system installs and updates, but of particular interest in this release are

  • updating previously imported keys
  • manipulating the rpm keyring via rpmkeys
  • testing the new v6 package format compatibility with 3rd party software (requires building packages with %_rpmformat set to 6)

:link: User Experience

  • The most noticeable change is that RPM now refuses to install packages whose signature hasn’t been positively verified, whether due to being unsigned, missing key or otherwise. This can be worked around by supplying --nosignature on the command line, or more permanently, changing the %_pkgverify_level macro to the former default of digest, but these should be only temporary measures, users are encouraged to import necessary keys and/or setup automatic signing for their (local) builds instead.
  • Signature and key related output has changed: upper/lower case is followed consistently in related output, and OpenPGP keys are always addressed either by their fingerpring hash or the full keyid, whereas previously a collision prone, short key id was used.
  • rpmkeys is now the official tool for manipulating the rpm keyring. Other methods such as manipulating gpg-pubkey pseudo-packages manually are deprecated and should be updated to either the rpmkeys tool or the newly provided keyring APIs.

:link: Dependencies

  • The soname does not change so no rebuilds are required for dependencies or otherwise
  • There are no dependencies to other Fedora changes.
  • This is the first version of rpm built as C++, so rpm gains a runtime dependency on libstdc++.
  • Signing with Sequoia additionally requires sequoia-sq >= 1.0, but this is an optional dependency and even then, only for signing packages.

:link: Contingency Plan

  • Contingency mechanism: Revert back to RPM 4.20
  • Contingency deadline: Beta freeze
  • Blocks release? No

:link: Documentation

Last edited by @amoloney 2025-03-10T12:46:52Z

Last edited by @amoloney 2025-03-10T12:46:52Z

4 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

As I understood it, this makes it available and only if it is available we can choose to build more secure packages. So an absolute yes!

4

In addition to the discussion in the releng ticket…

Is there some idea of when adopting the v6 format might happen?
Or it’s still too early to tell there?

Is there a timeline as to when this might be able to land?
The sooner the better to allow for a long test window (but of course after the change is approved).

1 Like
5

The plan is to land it in early April, assuming it gets approved of course.

For those wanting an early taste, I have ~daily-weekly snapshot builds of the rpm devel tree at pmatilai/rpm-snapshot Copr - just remember this is not any released version, not even alpha.

As for moving to v6, it would be a goal for RHEL 11. Whenever that’s due - not exactly tomorrow. So while there’s no pressure to switch right now, people do need to start looking into that once 6.0 is out.

6

Just FWIW, I’m more likely to notice questions on the fedora devel mailing list where most of the 6.0 discussion is taking place. This forum is just not along my daily routes.