Connexion Premium

Fedora 45 débarque en bêta : le plein de nouveautés, surtout pour la sécurité

Chapeau la distrib'

Fedora 45 débarque en bêta : le plein de nouveautés, surtout pour la sécurité

Illustration : Flock

Fedora 45 vient d’entrer dans sa phase bêta. Les nouveautés sont assez nombreuses, notamment sur la sécurité et les paquets reproductibles.

Fedora est le laboratoire à ciel ouvert de Red Hat. La distribution est connue pour être pionnière dans ses choix technologiques, comme le choix du serveur d’affichage Wayland par défaut dès la version 25, longtemps avant les autres distributions (et les bugs de jeunesse qui allaient avec).

Comme Ubuntu, Fedora dispose d’un rythme biannuel, au printemps et à l’automne. La nouvelle mouture 45 est ainsi prévue pour le 20 octobre, ou le 27 en cas de problème. Maintenant que la bêta est disponible, on peut observer ses nouveautés, parmi lesquelles une hausse manifeste du niveau de sécurité.

Toutes les variantes du système peuvent être téléchargées (images ISO) depuis le site officiel. Sur la page de téléchargement, il faut penser à activer le sélecteur d’affichage pour la bêta. Depuis l’annonce officielle, les différents liens pointent tous directement vers les versions 45.

Composants de base

La bêta de Fedora 45 est livrée avec le noyau Linux 7.2, la dernière révision stable (sortie le 16 aout). Parmi les nouveautés de ce dernier, le Cache Aware Scheduling permet à l’équilibrage de charge de tenir compte du cache de dernier niveau au sein des processeurs. Phoronix, connu pour ses tests de performances, indiquait en outre que le noyau 7.2 introduisait des gains mesurables de performances pour les processeurs AMD et Intel. Entre autres nouveautés, on trouve une première prise en charge du HDMI 2.1 FRL dans le pilote AMDGPU, le support du protocole USB4STREAM d’Intel ou diverses prises en charge dans KVM de fonctions de sécurité propres à AMD et Intel.

Comme toujours avec Fedora, la version proposée par défaut pour les PC, Workstation, est fournie avec GNOME, qui passe pour l’occasion en version 51. Cette mouture n’est pas finalisée, même si les composants en bêta sont remplacés par leurs équivalents RC (Release Candidate) après l’installation de Fedora 45. GNOME 51 inaugure des curseurs au format SVG (déjà présents dans KDE), une nouvelle interface de gestion des empreintes digitales, le support de la connexion distante multi-utilisateurs via Kerberos, de nouveaux réglages pour le pavé tactile, de meilleures performances pour Agenda ou encore le nettoyage du code auparavant lié aux anciens pilotes NVIDIA. Pour les personnes n’appréciant pas GNOME, KDE Plasma 6.7 est disponible dans une version dédiée.

Côté développement, la chaîne GNU passe à GCC 16.2, binutils 2.47, glibc 2.44 et gdb 17.2. S’y ajoutent LLVM 23 pour l’ensemble des sous-projets, Go 1.27, Python 3.15, Perl 5.44 et Lua 5.5. Dans les notes de version de la distribution, on peut lire que plusieurs changements cassent la compatibilité. Par exemple, Setuptools 82 supprime le module pkg_resources. Pandas passe de la 2.3 à la 3.0, avec une gestion des chaînes revue, un comportement copie-sur-écriture cohérent et la suppression de fonctionnalités dépréciées depuis longtemps. Même chose avec libxml2, dont le passage de la 2.13.9 à la 2.15.3 s’est accompagné d’un changement d’ABI, imposant une recompilation de masse avec dépréciation des liaisons Python.

Parmi les autres changements, Podman 6 est une des mises à jour les plus lourdes de conséquences. Elle « inclut des changements importants de rupture de l’API et de la ligne de commande, de nouvelles fonctionnalités, ainsi que la suppression finale de composants obsolètes tels que slirp4netns, cgroups v1 et le backend BoltDB », prévient Fedora. Citons également le passage de MySQL de la version 8.4 à 9.7, et celui de MariaDB de la version 11.8 à la 12.3. NetworkManager prend en charge par défaut les réseaux « IPv6-mostly ».

Sécurité : plusieurs serrages de vis

Plusieurs changements importants sont présents dans Fedora 45. D’abord, l’équipe indique avoir franchi la barre des 90 % de paquets reproductibles.

Pour comprendre l’intérêt, rappelons qu’un paquet est dit « reproductible » si, à partir du même code source, du même environnement de compilation et des mêmes instructions, n’importe qui peut régénérer une copie identique bit à bit du paquet publié. En clair, il s’agit d’un gage de sécurité de la chaine d’approvisionnement : c’est la garantie que le binaire téléchargé correspond bien au code source publié. Dans le cas de Fedora, toute non-reproductibilité détectée est considérée comme un bug et est traitée comme telle, via un rapport. La distribution n’est pas la seule à progresser dans ce domaine, d’autres comme Arch Linux ou NixOS font de même.

On reste dans le sujet avec la vérification désormais obligatoire des signatures par le gestionnaire de paquets RPM. Un mode de vérification stricte, conformément au comportement en amont introduit par la version 6.0, comme nous l’indiquions il y a un an. Ainsi, seuls les paquets dont la signature est vérifiée peuvent être installés, sauf dérogation explicite avec --nosignature ou l’API correspondante. Les RPM compilés localement et non signés sont directement concernés. Côté Fedora, ce changement se fait dans la foulée du passage à RPM 6.1.

Fedora 45 restreint également ptrace par réglage global dans le noyau qui retire par défaut certaines permissions de débogage aux utilisateurs non privilégiés. L’objectif est d’empêcher un logiciel malveillant d’inspecter les autres processus du même utilisateur. En revanche, si des outils de débogage sont installés, un fichier sysctl rétablit le comportement classique de Fedora 44 et des versions précédentes.

Autre changement significatif, le changement de fournisseur par défaut du service Secret. On passe ainsi de KWallet et GNOME Keyring à oo7. Écrit en Rust, il implémente la même interface D-Bus org.freedesktop.secrets, et se veut une alternative légère utilisable sur tous les environnements. Il est développé dans le cadre du projet linux-credentials et sert déjà de service de secrets natif pour COSMIC Desktop. D’après la fiche Fedora, oo7 doit permettre un modèle d’autorisation limitée par application ou par service, ouvrir la voie à l’authentification FIDO2 et mieux encadrer l’accès des applications isolées aux secrets.

On trouve d’autres modifications liées à la sécurité, comme l’interdiction par DNF5 de changer de fournisseur par défaut. Un changement important, car à moins d’une manipulation spécifique, un paquet installé ne peut donc plus être remplacé automatiquement par celui d’un autre fournisseur. Signalons aussi que chpasswd et newusers passent désormais par PAM et appliquent donc les politiques de mots de passe du système.

Commentaires (24)

votre avatar
ba que du cool, en plus avec le 7.2 il y aura le support du Fan Controller de Arctic.
votre avatar
Rien ne vaut la tranquilite linux-mint :)
votre avatar
Rien ne vaut les paquets outdated et un support wayland propre prévu pour 2050 de linux mint
votre avatar
En tout cas les principaux paquets dont j'ai besoin sont plutot a jour, avec en bonus un kernel 7.0.
D'accord sur le support wayland mais ca s'en vient.

tout les gouts sont dans la nature!
votre avatar
Bah j'étais du même avis et franchement avec le temps, Fedora est devenue ma distrib préférée. C'est stable, dnf est aussi simple à prendre en main qu'apt (c'est littéralement les mêmes commandes).

Pour mon gamin je lui ai même mis une Fedora Cinnamon et ça tourne nickel.
votre avatar
J’ai découvert un peu par hasard la distrib en version Silverblue. Elle est aussi devenue ma distrib principale. Elle est d’une stabilité impressionnante, et la gestion par flatpak est d’une grande facilité.
votre avatar
Les migrations d'une version +1 fonctionnent bien ?
votre avatar
Pour l'instant j'ai pas eut de problèmes. J'ai commencé avec fedora 40 et j'ai sauté régulièrement de version, la je viens de passer à 44.
Alors il y a parfois quelques problèmes avec les drivers NVIDIA car j'ai perdu le support de ma carte pendant un temps (mais j'ai freeze la version de l'ancien driver). Pour jouer de temps en temps j'ai pas de problèmes.
votre avatar
Oui très bien, je fais des montées de version depuis fedora 40, sans problème. Quelques petits couacs à régler lors du passage à 44 avec les dépôts rpmfusion, mais rien de très compliqué.
votre avatar
"paquets reproductibles" : on en apprend tous les jours. Je ne savais même pas que c'était possible. Il y a quelques (nombreuses) années, c'était impossible. Il y avait toujours un timestamp qui traînait quelque part.
votre avatar
Ça me rappelle que dans ma boite, on avait patché les objets générés par le compilateur pour qu'il y ait toujours le même timestamp afin justement d'avoir des objets identiques. :D
votre avatar
Personnellement, je préfère centrer les politiques et mécanismes de mise à jour et d'historisation sur du versionnage sémantique que sur des checksums ou des timestamps.
votre avatar
Oui mais justement, ce n'est pas qu'une question de mise à jour et d'historisation, c'est aussi une question de sécurité, par exemple pour s'assurer que rien|aucun processus intermédiaire n'a modifié le code ou le paquet en cours de route : https://docs.fedoraproject.org/en-US/reproducible-builds/#_benefits
votre avatar
Ben il faut signer ses paquets ... la signature faisant foi, avoir des paquets reproductibles au bit près n'est pas nécessaire. Un bon CICD prend ça en compte. En plus il ne faut pas oublier que les paquets rpm gèrent déjà deux axes de versionning: versionning du code source et versionning du paquet. D'un point de vue sécurité d'approvisionnement, c'est l'authenticité qui compte , d'un point de vue mises à jour, pour peu que le paquet soit authentique, c'est les versions (paquet+codebase) qui comptent. vouloir du paquet identique au bit près indique plutôt un échec à avoir intégré les autres concepts (authenticité et versioning)... à moins que l'on veuille en plus compiler en miroir pour prouver le contenu d'un paquet authentique à posteriori, ce qui n'a généralement d'intérêt que pour des audits extrêmes ou des activités post-mortem pour confirmer un truc qu'on savait déjà.
votre avatar
Ben non, il y a diverses manières de dénaturer/traffiquer un code source, d'ailleurs je vais citer le lien que j'ai posté auparavant :

  • overheated memory on one builder does bit flips, corrupting output rpms in a subtle way

  • detect if a builder machine was compromised in some sort of a supply-chain attack to inject rogue code into the rpms

  • (beaucoup de points sur le débuggage)

votre avatar
Sérieusement?


  • Utiliser de la ram avec ECC...




  • Utiliser des contrôles d'authenticité sur l'upstream (signatures), éventuellement un service de validation de l'upstream (test, analyse différentielle, analyse comportementale) , et des dépôts upstream stabilisés. (signature = contrôle d'intégrité et d'authenticité)... une reproductibilité bit-perfect d'un package n'est utile qui si on a mal travaillé en amont. Et les gens qui galvaudent les précautions de base sont peu susceptibles de gérer correctement un processus de rebuild continu basé sur ce maigre concept.




  • D'accord sur ce point...

votre avatar
Bah c'est exactement comme ça qu'on eu la faille xz : le build CI/CD détectait l’environnent github et ne produisait pas le même build qu'en local.
votre avatar
oui, bon, le blâme ici c'est d'avoir fait un mauvais cicd avant tout. Il n'y a qu'un seul cicd qui compte, qu'une seule source de vérité acceptable. Si tu qualifie ton software sur base d'un build local mais que tu livre le résultat du cicd, c'est que tu n'as même pas comprise le principe du cicd.
votre avatar
Bah alors je ne pas compris le principe du CICD, tous les projets sur lesquels je suis intervenu, le CICD tourne dans github, sauf qu'avant de pousser il faut bien développer et tester en local... A vrai dire je ne vois pas comment on pourrait collaborer si le CI CD ne tournait qu'en local ???
votre avatar
mwais, il y a pas mal d'entreprises qui se ratent en mettant leur cicd dans github. Mais bon, quand on veut donner les clefs du royaume à Microsoft, il y a une certaine logique... reste que si tu développes sur ton pc, que tu teste sur ton pc, et puis que tu confies ta release à un pipeline magique que tu ne contrôles pas ou mal... et bien c'est tout de même ta faute...
votre avatar
On sait même faire encore mieux que de simples paquets reproductibles : la distribution complète reproductible. NixOS fonctionne ainsi : tu peux avoir 1500 machines clones (matériel comme logiciel), les 1500 auront des binaires strictement identiques et fonctionneront strictment de la même manière (donc, hors problème lié au matériel, soit aucune n'a de bug, soit le même bug sera sur les 1500).
votre avatar
IPv6-mostly
C'est possible d'en savoir plus à ce sujet??
votre avatar
Je me suis aussi posé la question. Après une recherche rapide, le terme serait utilisé en référence à "IPV6-Only", pour désigner un réseau supportant encore IPV4 mais tentant à devenir IPV6-Only. Dans ce cas, l'IPV6 est la norme, et IPV4 l'exception.

C'est ce que j'en ai retenu très succintement. Merci de me corriger ou d'apporter des précisions indispensables si je suis passé à côté.
votre avatar
Ue recherche sur internet, indique qu'un brouillon de l'IETF porte ce nom:
https://www.ietf.org/archive/id/draft-link-v6ops-6mops-01.html
1. Introduction
While most network operators initially deploy IPv6 alongside their existing IPv4 infrastructure, pure IPv6-only networks remain uncommon outside of the mobile carrier space. This dual-stack approach is seen as a necessary transition phase, allowing operators to gain experience with IPv6 while minimizing disruption.
However, dual-stack networks do not address the core problem driving IPv6 adoption: IPv4 address exhaustion. They still require the same amount of IPv4 resources as IPv4-only networks. Even worse, this dual-stack approach has been demonstrated to be a long-term crutch, frequently masking problems that would otherwise be exposed and remedied as normal operational workflows. Many applications still rely on IPv4, creating a chicken-and-egg problem: IPv6-only networks seem impractical with so many incompatible applications, yet applications continue to rely on IPv4 because IPv6-only networks are rare.
The less control a network operator has over devices and applications, the more difficult it is to break IPv4 dependencies and move to IPv6-only. This is particularly challenging in enterprise networks with legacy IPv4-dependent applications and public Wi-Fi networks where operators cannot guarantee device compatibility.
To enable a gradual transition, operators need to identify which devices can function in IPv6-only mode and which cannot. Creating separate network segments for each type introduces complexity and scalability issues – a major hurdle to IPv6-only adoption.
A more desirable approach is to deploy an "IPv6-mostly" network that provides IPv4 on demand. This allows IPv6-capable devices to remain IPv6-only while seamlessly supplying IPv4 to those that require it. An IPv6-mostly network allows Endpoints to operate at the highest level of their network stack evolution, on demand, while still allowing for legacy compatibility.
This document explores the requirements, recommendations, and challenges associated with deploying IPv6-mostly networks in enterprise and public Wi-Fi environments. While the principles discussed may be applicable to other network types, this document's focus remains on these specific use cases.
Je n'ai pas trouvé d'informations francophone sur le site lafibre.info ou sur bortzmeyer.org