Da ba dee da ba di

La victoire démocrate aux États-Unis est claire, tant sur la Chambre des représentants que sur le Sénat. Que signifie la prise du pouvoir au Congrès pour le secteur de la tech ? S’il est encore trop tôt pour établir des prévisions sur l’ensemble de l’industrie, un domaine en particulier va être rapidement concerné : l’IA.

Les pronostics semblaient clairs depuis des semaines, mais la victoire des démocrates est pour le moins éclatante à l’issue des midterms américaines. Ces élections se produisent pour rappel à mi-mandat du président élu et lui sont généralement défavorables. Dans le cas présent, le désaveu pour Donald Trump est cinglant, puisque les démocrates vont contrôler les deux chambres du Congrès, qui appartenaient toutes deux aux républicains jusqu’à présent. Le changement se fera officiellement en janvier.

Comme le signale notamment Reuters, le président américain paye la guerre déclenchée contre l’Iran le 28 février, la flambée des prix des carburants ou encore, de manière générale, le coût de la vie dans le pays. Reuters cite un sondage en sortie des urnes, selon lequel 75 % des personnes interrogées ont indiqué être « en colère » ou « insatisfaites » de la direction prise par les États-Unis. 70 % ont également dit souhaiter un rôle renforcé du Congrès sur le contrôle de l’exécutif.

Ces élections ont également une caractéristique particulière : le secteur de la tech, tout particulièrement l’intelligence artificielle, a joué un rôle. Les entreprises concernées vont devoir s’adapter.

Désaveu pour les milliardaires de la tech

Si l’on en croit CNBC, le scrutin est un désaveu des milliardaires de la tech. Les démocrates auraient ainsi pris le Congrès sur fond de mécontentement face aux prix, à la corruption, mais aussi face à la construction des centres de données pour l’IA. Des datacenters dont l’installation est devenue hautement politique ces derniers mois.

Toujours selon CNBC, le Texas concentre une grande partie des projets prévus. La nouvelle gouverneure Gina Hinojosa a fait campagne pour suspendre les nouveaux projets jusqu’à l’adoption de règles plus strictes, autrement dit un moratoire.

Business Insider et TIME s’intéressent de leur côté à Elon Musk, premier donateur du cycle électoral, avec au moins 446 millions de dollars, dont la moitié pour le seul Texas via des super PAC alliés, sans pour autant empêcher l’État de basculer. Un changement conséquent d’ailleurs, puisque non seulement le Texas n’avait pas eu de gouverneur démocrate depuis 1988, mais le nouveau sénateur élu, James Talarico, l’emporte avec 10 points d’avance sur son adversaire Ken Paxton.

Une poignée de mains et patatras

Une nouvelle faille critique a été découverte dans le noyau Linux. Avec un score CVSS de 9,8 sur 10, sa dangerosité frôle la note maximale, permettant une exploitation à distance. Selon la distribution utilisée, le correctif peut être disponible ou non.

Les distributions Linux reçoivent peu à peu de nouveaux noyaux contenant un correctif pour la faille estampillée CVE-2026-98432. La situation est très variable selon les systèmes, Red Hat ayant publié de nouveaux noyaux par exemple, alors que chez Canonical, les correctifs pour Ubuntu restent pour l’instant cantonnés au dépôt de test, sans date de publication générale. D’autres encore ont réglé le problème au cours des deux dernières semaines.

La faille est connue publiquement depuis le 15 octobre. Elle est présente dans le noyau Linux depuis sa version 4.4, qui remonte à une dizaine d’années.

Deux cœurs pour une même mémoire

Pour comprendre comment fonctionne la faille, rappelons d’abord quelques bases. Lorsqu’un serveur accepte une connexion TCP, il échange d’abord trois messages avec le client : le client demande l’ouverture (SYN), le serveur accepte (SYN-ACK), puis le client confirme (ACK). Pendant cet échange, le serveur garde en mémoire certaines informations envoyées par le client, les options IP.

Tant que l’échange n’est pas terminé, le noyau Linux range ces informations dans une fiche provisoire (demande en attente). À la réception du dernier message (ACK), il crée la fiche définitive de la connexion. Au lieu de recopier les options IP dans cette nouvelle fiche, il se contente d’y noter leur emplacement en mémoire. Les deux fiches désignent alors la même zone mémoire, et la fiche provisoire peut encore être utilisée.

On peut voir venir le problème. Il survient quand deux cœurs du processeur travaillent en même temps, soit un scénario très commun sur n’importe quel serveur aujourd’hui. Si le client renvoie sa demande de connexion, un cœur peut être en train de lire ces informations pour y répondre, tandis que l’autre vient de les effacer en fermant la connexion. Le premier lit alors une mémoire qui ne lui appartient plus et qui peut tout à fait avoir été réaffectée à un autre processus. Ce mécanisme peut être exploité, la faille étant donc de type use-after-free (utilisation de mémoire après libération).

S’il veut déclencher ce conflit et donc exploiter la faille, le pirate n’a pas besoin de compte. Il lui « suffit » d’envoyer des demandes de connexions contenant certaines options IPv4 peu utilisées (comme Record Route ou Timestamp) vers n’importe quel port TCP ouvert. Les connexions IPv6 ne sont pas concernées.

De fait, le correctif à appliquer est simple : il impose au noyau d’attendre que plus personne ne lise les informations en mémoire avant de les effacer.

La gravité de la faille ne fait pas consensus

Officiellement, le score CVSS est bien de 9,8. Et pour cause : l’exploitation se fait avec un simple accès réseau, ne semble pas complexe, ne réclame aucun privilège particulier ni interaction côté victime, et l’impact potentiel sur la confidentialité, l’intégrité et la disponibilité est élevé. La faille peut en effet servir aussi bien à déclencher un plantage qu’à voler des informations.

Red Hat, dans sa fiche sur la vulnérabilité, considérait initialement cette faille comme « modérée », avec un score de 5,9. L’éditeur s’est pourtant ravisé, s’alignant sur la note de 9,8 et la considérant donc comme critique. Mais tous ne l’ont pas fait.

Chez AWS (pour sa distribution Amazon Linux) par exemple, on considère que la faille a un score de 8,1, ce qui la place dans la catégorie « importante ». Amazon considère que ce « problème entraîne principalement un plantage du système menant à un déni de service (DoS) ou une possible corruption de la mémoire ».

Canonical, dans son bulletin du 2 novembre sur la faille, reprenait directement la note de 9,8.

Qui est à l’abri ?

Comme indiqué, la situation dépend largement du système utilisé. Côté Ubuntu par exemple, si vous utilisez une mouture 26.10 à jour, aucun problème : le correctif est présent dans le noyau 7.3.0 - 10.10. En revanche, pour toutes les autres versions, il faut attendre ou installer un correctif pas tout à fait finalisé. Ubuntu 26.04, 24.04 et 22.04 peuvent ainsi puiser dans le dépôt -proposed pour des révisions des noyaux (respectivement les branches 7.0, 6.8 et 5.15). Pour les versions plus anciennes, le correctif est en préparation.

Sur Amazon Linux, le correctif a été distribué entre les 24 et 30 octobre, selon les versions. Pour Red Hat, on l’a vu, les correctifs sont également disponibles. D’autres distributions ont réagi plus tôt, notamment Debian, SUSE ou encore Oracle Linux, qui ont toutes reçu des correctifs durant la seconde moitié d’octobre.

La situation suffit en tout cas à justifier une mise à jour rapide. On parle tout de même d’un défaut accessible sans authentification sur tout port TCP IPv4 en écoute, présent depuis dix ans, avec au minimum un risque de déni de service et de fuite mémoire.

L’exécution de code à distance n’a été en revanche démontrée que par un seul acteur : Anthropic. Dans un billet du 27 octobre, l’entreprise a en effet indiqué qu’elle avait utilisé un modèle de recherche interne pour créer une chaine d’exploitation aboutissant aux droits root, dans des conditions particulières. Il ne semble pas pour l’instant que la vulnérabilité soit réellement exploitée, mais certains chercheurs évoquent désormais une activité a priori malveillante pour chercher les serveurs exposés.

Le comite n'a pas contracté

Pour la première fois de son histoire, le langage C++ a échoué à réunir assez de votes au sein de l’ISO pour une nouvelle version. Le C++ 26 n’a pas été ratifié, faute d’un accord sur plusieurs points, dont le principal est le concept de contrat. Explications.

Le 23 octobre avait lieu le vote des organismes nationaux sur le projet de norme internationale (DIS). Le lendemain, Robert Seacord, qui dirige le comité du langage C à l’ISO, annonçait sur LinkedIn que le texte avait été désapprouvé, y évoquant un « jour triste pour la communauté C++ ».

Une première pour le C++

Pour être adopté, un projet doit réunir deux conditions. Il lui faut non seulement les deux tiers des voix des membres participants, mais les votes négatifs ne doivent pas non plus dépasser le quart des votants. Or, C++ 26 n’a obtenu que 12 voix sur 20, soit 60 %, alors que 14 étaient nécessaires. En outre, les votes négatifs ont atteint 9 sur 22, soit 41 %. Le projet C++ 26 a donc échoué sur les deux tableaux.

Selon Mateusz Pusz, membre du comité national polonais qui a consulté le résultat officiel, neuf pays ont voté contre : Danemark, Finlande, Iran, Italie, Japon, Luxembourg, Roumanie, Espagne et Suède. La France et l’Irlande se sont abstenues tout en adressant des commentaires techniques. La Pologne et les États-Unis se sont abstenus sans commentaires.

C’est la première fois qu’une nouvelle version du langage n’est pas normalisée par l’ISO. Pour Robert Seacord, aucune norme de langage n’avait jamais échoué à ce stade. Selon Daveed Vandevoorde, membre du groupe de direction du comité C++, c’est même encore plus significatif : aucun projet antérieur n’avait reçu un seul vote contre.

Au cœur des débats, les contrats

Le C++ 26 dresse une longue liste de nouveautés, parmi lesquelles les contrats. En développement, un contrat inscrit dans la déclaration d’une fonction ce qu’elle exige de son appelant et ce qu’elle garantit en retour. Il s’agit respectivement de la précondition et de la postcondition. Par exemple, une fonction de racine carrée peut exiger un nombre positif et promettre un résultat tout aussi positif.

Cette idée n’est pas nouvelle, comme l’indique le site Les Joies du Code. Le principe a été popularisé dans les années 1980 par l’informaticien français Bertrand Meyer avec son langage Eiffel. D’autres langages plus modernes, comme Ada et D, l’intègrent également. Le contrat figure dans la déclaration, à la vue de tous (aussi bien les appelants que le compilateur et les outils d’analyse). Pour ses défenseurs, il sert même de documentation qui ne peut pas devenir obsolète en silence.

Pour donner une idée de l’âge du sujet, le comité C++ travaille dessus de manière concertée depuis 2004, et une première version avait été proposée pour C++ 20, avant d’être supprimée en 2019. La version actuelle, présente dans la proposition de C++ 26 récemment refusée, avait pourtant reçu l’aval d’un sous-comité technique en février 2025, par 100 voix contre 14.

Alors que s’est-il passé ? En fait, si l’idée fait globalement consensus, sa conception divise. Dans C++ 26, le code source ne décide pas si un contrat est vérifié. Le texte définit quatre comportements possibles : ignorer la vérification, l’effectuer en signalant l’erreur sans s’arrêter, l’effectuer et arrêter le programme, ou l’arrêter immédiatement sans traitement intermédiaire.

Problème, le choix revient à l’implémentation, autrement dit à une option de compilation. Ainsi, une même règle écrite par le développeur peut donc être appliquée strictement, simplement signalée ou ignorée selon la manière dont le programme est construit. Dans son billet, Mateusz Pusz avait résumé ainsi la problématique : une assertion de contrat est-elle une vérification que la compilation peut supprimer, ou une garantie sur laquelle le programme peut compter ?

Deux camps irréconciliables

Sans surprise, les opposants reprochent la possibilité de désactiver les vérifications. Selon eux, cela revient à la pratique déjà connue de tester du code avec des contrôles puis à les supprimer en production. Ils préfèrent que ces vérifications soient toujours actives, ce qui aurait un coût estimé par Google à 0,3 %.

Ils lui reprochent également son inachèvement, car les contrats sur les fonctions virtuelles ont été repoussés à C++ 29. Dans ce camp, on retrouve notamment Bjarne Stroustrup, le propre créateur du C++. Il exprime son rejet des contrats sous cette forme depuis des années, comme l’indiquait The Register en mars dernier.

Pour les défenseurs en revanche, toutes ces critiques ont déjà reçu des réponses. Ils craignent également que le retrait ne repousse encore les contrats de plusieurs années. L’historique va d’ailleurs dans ce sens : après le retrait de C++ 20, il avait fallu six ans pour les remettre sur la table, dans une version plus modeste. En outre, ils reprochent à certains opposants d’avoir plaidé leur cause directement auprès des pays pendant le vote.

Et maintenant ?

D’abord, précisons qu’il y a peu de conséquences immédiates pour les développeurs. La situation est similaire avec les normes Wi-Fi : les compilateurs n’attendent pas la publication d’une norme pour implémenter un projet en cours de travail. Le vote ne modifie pas non plus ce qu’ils proposent déjà. Par exemple, la version 16 de GCC (sortie en avril) prend en charge les contrats à titre expérimental (avec l’option -std=c++ 26). Clang ne les intègre pas encore en revanche.

Quelle suite à présent ? Le comité WG21, le groupe de travail de l’ISO chargé du langage C++, doit se réunir à Búzios, au Brésil, du 16 au 21 novembre 2026. Il devra répondre à chacun des commentaires nationaux (que l’on ne peut pas consulter) et recommander une marche à suivre.

De là, il peut y avoir quatre possibilités : un projet révisé soumis à un nouveau vote de huit semaines, un nouveau projet de comité soumis à commentaires, une publication comme spécification technique, ou l’abandon pur et simple. Le président du SC22, sous-comité de l’ISO chargé des langages de programmation, devra choisir parmi les trois premières. Pour un abandon, il faut en revanche que tout le SC22 vote.

Pour l’instant, les camps sont divisés. Certains militent pour un nouveau vote sur le texte inchangé, d’autres pour retirer la seule fonction contestée afin que le reste passe. D’ici à ce que le problème soit tranché, il est probable que la date du vote glisse en 2027. La future norme pourrait alors changer de nom pour C++ 27.

Chapeau la distrib'

Fedora 45 est maintenant téléchargeable en version finale. Les nouveautés sont assez nombreuses, notamment sur la sécurité et les paquets reproductibles.

Mise à jour du 4 novembre

La version finale est désormais disponible au téléchargement. On peut récupérer les images ISO depuis le site officiel.

---

Article original du 16 septembre

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).

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

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.