Open Source & Tools

RPM 6.0.0: how I actually secure my open-source supply chain

by  • 

When I talk about open-source security, I’m not talking ideology—I’m talking measurable trust. The RPM 6.0.0 release (September 22, 2025) finally gives me solid building blocks for what I expect from a modern package system: locking down the trust chain, tracing artifact provenance precisely, and handling key rotations without breaking production.

Why this release changes my day-to-day

I want to prove a package comes from who it claims to, hasn’t been tampered with, and is signed under my internal policies. RPM 6 gets straight to it:

  • The v6 format is now the default build target (everything is 64-bit, with per-file MIME metadata). I stay in control: I can keep producing v4 if downstream isn’t ready, via a simple macro.
  • Signature verification is enabled by default. No more gray areas—my packages are verified systematically.
  • OpenPGP keys are identified by full fingerprint (no more ambiguous short IDs). That’s crucial to avoid collisions and mis-resolutions.
  • I can attach multiple signatures to the same package. Practically, that lets me separate roles: a build signature (pipeline), a release signature (publisher), and optionally an integrator signature (my org). From a supply-chain standpoint, this is a meaningful step toward multiple attestations.
  • On the crypto side, RPM 6 turns the page: MD5/SHA-1 are out, SHA-3-256 for the header and SHA-512 / SHA-3-256 for the payload. Better yet, OpenPGP v6 and PQC readiness (post-quantum) are supported. I can evolve without rewriting my world.

What I’m putting in place for my supply chain

In my organization, I structure the transition around four pillars.

1) Key governance and signing policy

I move everyone to full fingerprints (key = fingerprint) and standardize rpmkeys/rpmsign in our CI scripts.
I apply multiple signatures per package when it makes sense:

  • Build (CI identity),
  • Release (product identity),
  • Integration (the entity that assembles and deploys).

This separation helps me assign accountability and spot chain breaks. For rotations or revocations, I can add a signature without overwriting the previous ones, then re-sign to start clean.

2) A consistent verification policy (runtime and CI)

I harden the default stance: verification everywhere. For older packages (pre-4.14) signed with weak digests, I keep two documented options:

  • ignore those digests and rely on the strong signature only, or
  • explicitly re-enable the legacy behavior (I don’t recommend it, but I sometimes tolerate it in legacy segments).

What matters is consistency across CI, pre-prod, and prod.

3) Traceability and incident response

I leverage RPM 6’s ability to record configurable fingerprints into the database during verification. In plain terms: I keep markers that help me link a binary back to its source package. In supply-chain incident handling, that’s invaluable—less guesswork, faster answers.

4) A gradual v4/v6 transition without breaking downstream

I build v6 by default, but keep the format macro handy for components still stuck on v4. I publish a clear map: which repos accept v6, which remain v4, and how we migrate (windows, tests, acceptance criteria). That clarity prevents “surprise” regressions.

Tooling takeaways

  • rpmkeys and rpmsign finally have the ergonomics I wanted: import/export, key updates (from a pipe if needed), multi-signature without overwriting, and a choice of signing engine (GnuPG or Sequoia).
  • rpmbuild can emit v6 or v4 at will; I can auto-sign in CI if I declare the right identity.
  • The docs are cleaned up and versioned: I can train faster and reduce variability across teams.

My concrete adaptation plan

  • Standardize macros for format and signing in specs (v6 by default, documented v4 fallback).
  • Tool multi-signature in CI (role separation, key storage, proof logs).
  • Align verification policies (CI / staging / prod) and document how we treat inherited weak digests.
  • Upgrade runners (C++20, Python 3.10, deps) and validate signing paths (HSM/YubiKey where possible).
  • Enable RPMDB traceability to speed up supply-chain investigations.
  • Plan consumer-repo migration to v6 with clear exit criteria and non-regression tests.

My conviction

With RPM 6, I can set strong guarantees without hurting operations: multi-signature, full-fingerprint keys, and modern crypto make my software supply chain more auditable and less brittle against attacks. The v4/v6 coexistence saves me from a big-bang and lets me control the pace of migration.

It’s not just an update; it’s a shift in posture. We don’t just “build packages” anymore—we administer a chain of trust. And with RPM 6.0.0, I finally have the right levers to prove it.

Enjoy !