Fedora 45 sort le 3 novembre avec GNOME 51, kmscon et la vérification de signature RPM obligatoire
Le 3 novembre 2026, Fedora Linux 45 est livré après deux reports, avec GNOME 51, le noyau Linux 7.2 et un durcissement notable : signature RPM obligatoire, builds reproductibles et restriction de ptrace par défaut. Les administrateurs doivent anticiper la vérification de signature sur les paquets et la migration des dépôts RPM hors de /etc.
3 novembre 2026. Fedora Linux 45 est livré sur les miroirs, après que Aoife Moloney, architecte des opérations du projet, a confirmé que le candidat RC-1.4 passait toutes les barrières de livraison. 3 novembre 2026, même jour. La décision « GO » intervient après deux reports successifs : une compose manquée début octobre, puis une date du 22 octobre morte sur un paquet de bugs bloquants. 3 novembre 2026, toujours. La version embarque GNOME 51, KDE Plasma 6.8.1, le noyau Linux 7.2, et surtout un durcissement de plateforme : signature RPM obligatoire, builds reproductibles et ptrace restreint par défaut. L’essentiel tient en une phrase : pour la première fois, la sécurité de la chaîne d’installation n’est plus une option qu’on active, mais l’état par défaut.
Pour un administrateur, la sortie de Fedora 45 n’est pas qu’un nouvel ensemble de paquets. C’est un changement de contrat sur la signature des paquets et l’emplacement des dépôts, qui se prépare avant la mise à jour.
Le GO qui a mis deux semaines à venir
Le feu vert est un soulagement plus qu’une surprise. La sortie a glissé deux fois : une cible de début octobre a sauté parce que la compose n’était pas prête, puis une cible du 22 octobre a été abandonnée devant une grappe de bugs bloquants — une image serveur AArch64 qui dépassait sa limite de taille, et un échec d’auto-activation LVM après une mise à niveau sur une installation LUKS. La semaine suivante, Adam Will, responsable QA, a passé en revue les derniers candidats bloquants lors d’une réunion publique dans le canal Matrix #fedora-meeting, de 18 h 02 à 19 h 28 UTC.
Deux cas sont révélateurs du processus. Le bug de phrase secrète SSH (#2558595), qui empêchait le déverrouillage automatique à l’ouverture de session après une mise à niveau depuis Fedora 44, a été rejeté comme bloquant : la fonction essentielle marche, et le correctif est déjà dans les candidats. Le vrai bloqueur, l’échec de démarrage d’un pool chiffré Stratis (#2543511), était corrigé à 80 % dans RC-1.3 et entièrement dans RC-1.4. « All blockers have been addressed », a conclu Will. Fedora préfère livrer tard et juste plutôt qu’à l’heure et cassé — c’est précisément ce qui donne du poids au GO.
Ce qui change réellement sous le capot
La nouveauté la plus visible est GNOME 51 sur l’édition Workstation et KDE Plasma 6.8.1 sur l’édition KDE, sur un noyau Linux 7.2. Mais ce cycle porte surtout des changements de plateforme.
kmscon remplace fbcon — la console virtuelle intégrée au noyau — par une solution en espace utilisateur, plus capable et plus sûre. ptrace est restreint par défaut : un processus non privilégié ne peut plus inspecter les autres processus, le genre de porte que les malwares aiment exploiter ; la fonctionnalité complète revient via un sysctl une fois les outils de débogage installés. La vérification de signature devient obligatoire dans RPM, dans la lignée de RPM 6.0 : un paquet doit porter une signature vérifiée pour s’installer, sauf dérogation explicite. Et les builds deviennent entièrement reproductibles, ce qui renforce la confiance dans la chaîne d’approvisionnement.
L’installateur gagne le support du stockage Stratis, y compris l’automatisation Kickstart et le partitionnement via Cockpit Storage. Les bureaux Atomic reçoivent un nouvel installateur WebUI qui remplace l’ancien Anaconda en GTK, avec installation à distance en HTTPS par code PIN.
La chaîne d’outillage est à jour : GCC 16.2, Python 3.15, Glibc 2.44, LLVM 23, RPM 6.1, Go 1.27. MySQL 9.7 et MariaDB 12.3 deviennent les valeurs par défaut. Deux changements structurels passent inaperçus mais comptent : les configurations des dépôts RPM migrent de /etc vers /usr, et oo7 devient le fournisseur par défaut du service Secrets, éloignant les bureaux de GNOME Keyring.
Pourquoi la signature obligatoire est le vrai sujet
Le changement qui mérite l’attention d’un administrateur n’est pas GNOME 51 : c’est la vérification de signature obligatoire. Jusqu’ici, installer un paquet non signé relevait d’un avertissement qu’on pouvait ignorer. Désormais, le paquet refuse de s’installer. Les conséquences sont concrètes.
Les dépôts tiers qui ne signent pas correctement leurs paquets, les scripts d’installation maison qui posent des .rpm bruts, et les outils qui contournaient la vérification vont échouer de manière visible. C’est exactement l’intention : rendre l’absence de signature impossible à ignorer. La contrepartie, pour les équipes qui maintiennent des dépôts internes, est de s’assurer que leurs clés de signature sont déployées et valides avant la migration.
Les builds reproductibles complètent le dispositif : un paquet reconstruit depuis les sources produit le même binaire. Deux mécanismes — la signature et la reproductibilité — répondent à deux menaces distinctes de la chaîne d’approvisionnement, la substitution et l’altération, et Fedora 45 active les deux par défaut. La restriction de ptrace ferme, elle, une porte locale que les malwares utilisent pour voler des secrets ou s’accrocher à un processus légitime.
Ce qu’il faut faire maintenant
La mise à niveau depuis Fedora 44 est le chemin nominal, mais quelques vérifications évitent des surprises le jour J.
- Auditer les dépôts tiers. Inventoriez les
.repoet leurs clés. Un dépôt sans clé valide fera échouer ses paquets après la migration. - Préparer les outils internes. Les scripts qui posent des RPM non signés doivent soit signer, soit documenter une dérogation explicite — à éviter.
- Comprendre le
sysctlde ptrace. Les équipes qui déboguent en production doivent connaître le réglage pour le réactiver là où c’est nécessaire. - Tester sur une image Atomic. Le passage d’Anaconda à l’installateur WebUI change les habitudes d’automatisation de déploiement.
Rien de tout cela ne bloque une installation neuve. Mais une mise à niveau de parc sans cet audit transforme un durcissement bienvenu en interruption de service le jour de la livraison.
Verdict
La sortie ne se juge pas à GNOME 51, mais au changement de défaut : signature RPM obligatoire, builds reproductibles, ptrace restreint. Si vous gérez un parc de postes Fedora, la migration se prépare en auditant les dépôts et les outils internes avant la bascule — la valeur est réelle, mais elle s’obtient en amont. Si vous exploitez des serveurs, les gains se concentrent sur la chaîne d’approvisionnement : un paquet qui s’installe est désormais un paquet qu’on peut retracer. La leçon dépasse la distribution : la sécurité qui compte n’est plus celle qu’on configure, mais celle qui refuse de se laisser désactiver par défaut.