Quand je parle de sécurité open source, je ne parle pas d’idéologie : je parle de confiance mesurable. La sortie de RPM 6.0.0 (22 septembre 2025) me donne enfin des briques solides pour faire ce que j’attends d’un système de paquets moderne : verrouiller la chaîne de confiance, tracer précisément l’origine des artefacts et gérer les transitions de clés sans briser la production.
Pourquoi cette version change mon quotidien
Je veux pouvoir prouver qu’un paquet provient bien de qui il prétend, qu’il n’a pas été altéré et qu’il est signé selon mes politiques internes. RPM v6 va droit au but :
- Le format v6 devient la norme de construction (tout est prévu en 64 bits, avec des métadonnées MIME par fichier). Je garde la main : je peux continuer à produire en v4 si mon écosystème en aval n’est pas prêt, via un simple macro.
- La vérification des signatures est activée par défaut. Fini les zones grises : mes paquets sont vérifiés systématiquement.
- Les clés OpenPGP sont identifiées par empreinte complète (plus d’ID courts ambigus). C’est un point fondamental pour éviter les collisions ou mauvaises résolutions de clés.
- Je peux apposer plusieurs signatures sur un même paquet. Concrètement, ça me permet de séparer les rôles : une signature de build (pipeline), une signature de release (éditeur), et éventuellement une signature intégrateur (mon SI). D’un point de vue supply chain, c’est un vrai pas vers la multiplication des attestations.
- Côté crypto, RPM 6 tourne la page : MD5/SHA-1 dehors, SHA-3-256 pour l’en-tête et SHA-512 / SHA-3-256 pour le payload. Mieux : OpenPGP v6 et préparation PQC (post-quantique) sont pris en charge. Je peux évoluer sans recoder mon monde.
Ce que je mets en place pour ma supply chain
Dans mon organisation, je structure la bascule autour de quatre axes.
1) Gouvernance des clés et politiques de signature
Je passe tout le monde à l’empreinte complète (clé = fingerprint), et j’uniformise rpmkeys/rpmsign dans nos scripts CI.
J’applique plusieurs signatures par paquet quand c’est pertinent :
- Build (identité CI),
- Release (identité produit),
- Intégration (identité de l’entité qui assemble et déploie).
Cette séparation m’aide à attribuer la responsabilité et à détecter les ruptures de chaîne. En cas de rotation ou révocation, je peux ajouter une signature sans écraser les précédentes, puis resigner pour repartir proprement.
2) Politique de vérification cohérente (runtime et CI)
Je durcis la politique par défaut : vérification active partout. Pour les vieux paquets (pré-4.14) signés avec digests faibles, j’ai deux options documentées :
- ignorer ces digests et ne m’appuyer que sur la signature forte,
- ou réactiver explicitement l’ancien comportement (je le déconseille, mais je dois parfois le tolérer dans des segments legacy).
L’important, c’est la cohérence entre ce que je fais en CI, en pré-prod et en prod.
3) Traçabilité et réponse à incident
Je profite de la capacité de RPM 6 à enregistrer des empreintes configurables dans la base lors des vérifications. En clair : je garde des marqueurs qui m’aident à re-relier un binaire à son paquet source. En gestion d’incident supply chain, c’est précieux : on gagne du temps et on évite les hypothèses.
4) Transition progressive v4/v6, sans casser l’aval
Je construis v6 par défaut, mais je garde le macro de format sous la main pour les composants encore bloqués en v4. Je publie une cartographie claire : quels dépôts acceptent v6, lesquels restent v4, et comment on migre (fenêtres, tests, critères d’acceptation). Cette clarté évite les régressions « surprises ».
Ce que je retiens côté outillage
rpmkeysetrpmsignont enfin le niveau d’ergonomie que j’attendais : import/export, mise à jour des clés (depuis un pipe si besoin), signatures multiples sans écrasement, choix du moteur de signature (GnuPG ou Sequoia).- rpmbuild peut générer v6 ou v4 au choix ; je peux auto-signer mes paquets en CI si je déclare l’identité adéquate.
- La documentation est assainie et versionnée : je peux former plus vite et réduire la variabilité entre équipes.
Mon plan d’adaptation (concret)
- Standardiser les macros de format et de signature dans les recettes (v6 par défaut, fallback v4 documenté).
- Outiller la multi-signature dans la CI (séparation des rôles, stockage des clés, logs de preuve).
- Aligner les politiques de vérification (CI / staging / prod) et documenter le traitement des digests faibles hérités.
- Mettre à niveau les runners (C++20, Python 3.10, dépendances) et valider les chemins de signature (HSM/YubiKey si possible).
- Activer la traçabilité côté RPMDB pour accélérer les enquêtes en cas d’incident supply chain.
- Planifier la migration des dépôts consommateurs vers v6, avec critères de sortie clairs et tests de non-régression.
Ma conviction
Avec RPM 6, je peux poser des garanties fortes sans dégrader l’opérationnel : la multi-signature, l’empreinte complète des clés et la modernisation crypto rendent mes chaînes logicielle plus auditable et moins fragile face aux attaques supply chain. La cohabitation v4/v6 m’évite le « big bang » et me laisse maîtriser le tempo de la migration.
Ce n’est pas qu’une mise à jour : c’est un changement de posture. On ne « fait » plus des paquets ; on administre une chaîne de confiance. Et avec RPM 6.0.0, j’ai enfin les bons leviers pour le prouver.
