L'automne en douceur

Fedora 43 vient de paraitre en bêta. Comme toujours avec cette distribution, on peut compter sur les dernières versions des paquets et des choix avant-gardistes. Mais si cette version se présente comme solide, elle propose peu de nouveautés visibles.

Les nouvelles versions de Fedora sont toujours attendues. Par une partie des utilisateurs bien sûr, ceux en quête de nouveautés. Mais aussi par les personnes qui observent l’évolution des distributions Linux en général. Fedora est le laboratoire à ciel ouvert de Red Hat et l’entreprise y teste en avance des choix et technologies, parfois de manière radicale, avant de les inclure dans sa propre distribution commerciale RHEL.

Côté utilisateurs cependant, Fedora 43 est assez calme. Ses changements les plus significatifs sont sous le capot.

L’habituelle modernisation généralisée

Contrairement à la plupart des distributions et à l’opposé d’une Debian, la philosophie de Fedora est de toujours proposer les dernières versions des paquets. Puisqu’il s’agit de la bêta, ces versions ne sont d’ailleurs pas toutes finalisées. On trouve par exemple le noyau Linux 6.17, qui est actuellement en RC6. Dans ce dernier, on peut trouver notamment des améliorations de performances pour le système de fichiers Btrfs, le support des processeurs Wildcat Lake d’Intel, la prise en charge de la Branch Record Buffer Extension pour ARM ou encore une amélioration du support des CPU et GPU.

Dans son édition classique Workstation, on retrouve bien sûr GNOME 49, dont la version finale est intégrée dans la bêta de Fedora et qui doit être annoncée aujourd’hui. Nous reviendrons donc très bientôt sur ses nouveautés. Cette version devait en tout cas désactiver X11 pour ne laisser que Wayland, mais l’équipe de développement a finalement repoussé cette bascule. La transition vers Wayland reste complexe, comme nous l’avons vu en détail récemment. Ce qui n’effraie pas Fedora, puisque la version 43 supprime les paquets liés à X11 et ne laisse que Wayland (et XWayland pour la compatibilité).

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

Côté KDE, c’est Plasma 6.4 qui est aux commandes. Rappelons que Fedora, depuis sa version 42, dispose d’une variante officielle KDE, qui n’est donc plus seulement un Spin.

De manière générale, on retrouve les dernières versions de Firefox, LibreOffice et des quelques applications livrées avec le système. Côté développement, c’est le même traitement : GCC 15.2, GNU Binutils 2.45, GNU C Library 2.42, GDB 17.1, LLVM 21, Golang 1.25, Perl 5.42, RPM 6.0, Python 3.14, PostgreSQL 18, Ruby on Rails 8.0, Dovecot 2.4, MySQL 8.4, Tomcat 10.1, etc.

Sous le capot, c’est beaucoup plus intéressant

Pour cette version en particulier, les évolutions les plus significatives sont sous le capot, loin du « simple » choix des versions pour les paquets les plus courants. Par exemple, l’installeur Anaconda, utilisé dans sa nouvelle mouture Web UI depuis Fedora 42, est désormais utilisé pour l’ensemble des Spins de la distribution et pour Fedora KDE. Pour la future version 44, Fedora compte s’en servir pour l’ensemble des éditions atomiques (dont Silverblue), tandis que Fedora 45 s’en servirait pour son édition Server. Après, les anciens composants GTK d’Anaconda seraient dépréciés.

Dans la même « veine », l’installeur se sert maintenant de DNF5 pour toutes les applications basées sur des paquets. Pour l’équipe de développement, c’est un pas supplémentaire vers la dépréciation de DNF4, qui est d’ailleurs entré en mode maintenance. En clair, plus aucune nouveauté ne lui sera ajoutée et les modifications ne concerneront que les corrections de bugs. Le passage à DNF5 est une réponse aux demandes de la communauté, car il doit simplifier les déploiements et rendre les installations plus rapides.

Citons également l’installation automatique des mises à jour dans Fedora Kinoite (version immuable sous KDE), la construction de Fedora CoreOS en utilisant Containerfile, la compression d’initrd avec zstd par défaut dans toutes les variantes du système, la réécriture complète de Greenboot (pour les systèmes basés sur bootc et rpm-ostree) en Rust, le retrait de python-nose (déprécié depuis cinq ans et incompatible avec Python 3.14), ou encore la prise en charge de la virtualisation confidentielle basée sur la plateforme TDX d’Intel.

On note aussi l’utilisation de RPM 6.0 dans Fedora 43. Comme la fiche du changement le précise cependant, cette adoption n’est réalisée que pour des questions de sécurité. Cette nouvelle version majeure améliore notamment plusieurs aspects dans la gestion des clés cryptographiques, en plus de la possibilité pour un paquet de supporter désormais plusieurs signatures. En revanche, Fedora n’adopte pas le nouveau format de paquet de RPM 6.0 par défaut. La génération se fait toujours sur la v4. L’équipe indique en outre que la vérification forcée des signatures était prévue pour Fedora 43, mais qu’elle n’a pas eu le temps de finir le travail.

La suite des opérations

Pour l’instant, la date prévue pour la version finale de Fedora 43 est fixée au 11 novembre. Il est souvent arrivé que l’équipe rate ses fenêtres de sortie, mais ce type de problème semble avoir été relégué au passé sur les dernières versions. On note que la période de test est donc assez longue, notamment face à une Ubuntu qui ne laisse le plus souvent que deux ou trois semaines entre la bêta et la version finale. Canonical devrait d’ailleurs sortir sous peu la bêta d’Ubuntu 25.10.

Sur l’installation proprement dite, elle ne réserve aucune surprise. Le passage à Anaconda dans Fedora 42 se confirme, l’assistant étant particulièrement simple : il n’y a que quatre panneaux avant que l’installation commence. Le reste, dont la création du compte principal, se fait après le redémarrage.

On conseillera comme toujours de ne pas utiliser le système sur une machine de production ou au moins utilisée quotidiennement. La bêta est surtout proposée aux développeurs pour vérifier la compatibilité de leurs applications.

Pour télécharger cette nouvelle Fedora, il suffit de suivre les liens de téléchargement affichés en tête du billet d’annonce, selon l’édition que vous souhaitez installer. Pour les Spins (Cinnamon, Xfce, MATE, Budgie…), il faut se rendre sur leur page dédiée, cliquer sur la variante voulue et activer le bouton « Show Beta downloads » à droite.

L'automne en douceur

Fedora 43 vient de paraitre en bêta. Comme toujours avec cette distribution, on peut compter sur les dernières versions des paquets et des choix avant-gardistes. Mais si cette version se présente comme solide, elle propose peu de nouveautés visibles.

Les nouvelles versions de Fedora sont toujours attendues. Par une partie des utilisateurs bien sûr, ceux en quête de nouveautés. Mais aussi par les personnes qui observent l’évolution des distributions Linux en général. Fedora est le laboratoire à ciel ouvert de Red Hat et l’entreprise y teste en avance des choix et technologies, parfois de manière radicale, avant de les inclure dans sa propre distribution commerciale RHEL.

Côté utilisateurs cependant, Fedora 43 est assez calme. Ses changements les plus significatifs sont sous le capot.

L’habituelle modernisation généralisée

Contrairement à la plupart des distributions et à l’opposé d’une Debian, la philosophie de Fedora est de toujours proposer les dernières versions des paquets. Puisqu’il s’agit de la bêta, ces versions ne sont d’ailleurs pas toutes finalisées. On trouve par exemple le noyau Linux 6.17, qui est actuellement en RC6. Dans ce dernier, on peut trouver notamment des améliorations de performances pour le système de fichiers Btrfs, le support des processeurs Wildcat Lake d’Intel, la prise en charge de la Branch Record Buffer Extension pour ARM ou encore une amélioration du support des CPU et GPU.

Dans son édition classique Workstation, on retrouve bien sûr GNOME 49, dont la version finale est intégrée dans la bêta de Fedora et qui doit être annoncée aujourd’hui. Nous reviendrons donc très bientôt sur ses nouveautés. Cette version devait en tout cas désactiver X11 pour ne laisser que Wayland, mais l’équipe de développement a finalement repoussé cette bascule. La transition vers Wayland reste complexe, comme nous l’avons vu en détail récemment. Ce qui n’effraie pas Fedora, puisque la version 43 supprime les paquets liés à X11 et ne laisse que Wayland (et XWayland pour la compatibilité).

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

Côté KDE, c’est Plasma 6.4 qui est aux commandes. Rappelons que Fedora, depuis sa version 42, dispose d’une variante officielle KDE, qui n’est donc plus seulement un Spin.

De manière générale, on retrouve les dernières versions de Firefox, LibreOffice et des quelques applications livrées avec le système. Côté développement, c’est le même traitement : GCC 15.2, GNU Binutils 2.45, GNU C Library 2.42, GDB 17.1, LLVM 21, Golang 1.25, Perl 5.42, RPM 6.0, Python 3.14, PostgreSQL 18, Ruby on Rails 8.0, Dovecot 2.4, MySQL 8.4, Tomcat 10.1, etc.

Sous le capot, c’est beaucoup plus intéressant

Pour cette version en particulier, les évolutions les plus significatives sont sous le capot, loin du « simple » choix des versions pour les paquets les plus courants. Par exemple, l’installeur Anaconda, utilisé dans sa nouvelle mouture Web UI depuis Fedora 42, est désormais utilisé pour l’ensemble des Spins de la distribution et pour Fedora KDE. Pour la future version 44, Fedora compte s’en servir pour l’ensemble des éditions atomiques (dont Silverblue), tandis que Fedora 45 s’en servirait pour son édition Server. Après, les anciens composants GTK d’Anaconda seraient dépréciés.

Dans la même « veine », l’installeur se sert maintenant de DNF5 pour toutes les applications basées sur des paquets. Pour l’équipe de développement, c’est un pas supplémentaire vers la dépréciation de DNF4, qui est d’ailleurs entré en mode maintenance. En clair, plus aucune nouveauté ne lui sera ajoutée et les modifications ne concerneront que les corrections de bugs. Le passage à DNF5 est une réponse aux demandes de la communauté, car il doit simplifier les déploiements et rendre les installations plus rapides.

Citons également l’installation automatique des mises à jour dans Fedora Kinoite (version immuable sous KDE), la construction de Fedora CoreOS en utilisant Containerfile, la compression d’initrd avec zstd par défaut dans toutes les variantes du système, la réécriture complète de Greenboot (pour les systèmes basés sur bootc et rpm-ostree) en Rust, le retrait de python-nose (déprécié depuis cinq ans et incompatible avec Python 3.14), ou encore la prise en charge de la virtualisation confidentielle basée sur la plateforme TDX d’Intel.

On note aussi l’utilisation de RPM 6.0 dans Fedora 43. Comme la fiche du changement le précise cependant, cette adoption n’est réalisée que pour des questions de sécurité. Cette nouvelle version majeure améliore notamment plusieurs aspects dans la gestion des clés cryptographiques, en plus de la possibilité pour un paquet de supporter désormais plusieurs signatures. En revanche, Fedora n’adopte pas le nouveau format de paquet de RPM 6.0 par défaut. La génération se fait toujours sur la v4. L’équipe indique en outre que la vérification forcée des signatures était prévue pour Fedora 43, mais qu’elle n’a pas eu le temps de finir le travail.

La suite des opérations

Pour l’instant, la date prévue pour la version finale de Fedora 43 est fixée au 11 novembre. Il est souvent arrivé que l’équipe rate ses fenêtres de sortie, mais ce type de problème semble avoir été relégué au passé sur les dernières versions. On note que la période de test est donc assez longue, notamment face à une Ubuntu qui ne laisse le plus souvent que deux ou trois semaines entre la bêta et la version finale. Canonical devrait d’ailleurs sortir sous peu la bêta d’Ubuntu 25.10.

Sur l’installation proprement dite, elle ne réserve aucune surprise. Le passage à Anaconda dans Fedora 42 se confirme, l’assistant étant particulièrement simple : il n’y a que quatre panneaux avant que l’installation commence. Le reste, dont la création du compte principal, se fait après le redémarrage.

On conseillera comme toujours de ne pas utiliser le système sur une machine de production ou au moins utilisée quotidiennement. La bêta est surtout proposée aux développeurs pour vérifier la compatibilité de leurs applications.

Pour télécharger cette nouvelle Fedora, il suffit de suivre les liens de téléchargement affichés en tête du billet d’annonce, selon l’édition que vous souhaitez installer. Pour les Spins (Cinnamon, Xfce, MATE, Budgie…), il faut se rendre sur leur page dédiée, cliquer sur la variante voulue et activer le bouton « Show Beta downloads » à droite.

Si les comptes Premium peuvent faire ce qu’ils veulent dans leur consommation de musique, les comptes gratuits sont fortement limités. Au-delà de la publicité récurrente, il n’est ainsi pas possible de lire spécifiquement un titre, ou dans l’ordre un album ou une liste.

Ce comportement vient de changer. Dans un communiqué publié lundi soir, Spotify annonce trois nouveautés, dont la principale est Pick & Play : on peut chercher un morceau et lancer sa lecture. De même, on peut lancer le titre que l’on souhaite dans un album ou une liste. Ces possibilités en ouvrent une autre : on peut désormais partager un titre avec les comptes gratuits pour qu’ils puissent le lire directement. Cette fonction simple n’avait jamais été disponible jusqu’à présent, étant réservée aux abonnés payants.

Spotify ne lève cependant pas toutes les barrières, afin que les comptes gratuits et Premium ne soient pas séparés uniquement par la présence de publicités. Si vous ouvrez un album ou une liste, le titre choisi basculera automatiquement vers un autre morceau aléatoire une fois fini.

On peut se demander pourquoi Spotify se décide maintenant à lever ces blocages pour les comptes gratuits. L’entreprise suédoise en avait peut-être assez de voir les utilisateurs partir vers YouTube quand ils voulaient écouter une musique spécifique, car quitte à avoir une publicité, le service de Google permet effectivement de lancer n’importe quel contenu.

Ces fonctions en accompagnent également une autre lancée récemment : le mode Lossless pour les comptes Premium (disponible en France dans les semaines à venir). Spotify a peut-être décidé de lancer en peu de temps plusieurs fonctions qui lui étaient réclamées depuis longtemps, pour redorer un blason abimé par la problématique des musiques générées par IA.

Si les comptes Premium peuvent faire ce qu’ils veulent dans leur consommation de musique, les comptes gratuits sont fortement limités. Au-delà de la publicité récurrente, il n’est ainsi pas possible de lire spécifiquement un titre, ou dans l’ordre un album ou une liste.

Ce comportement vient de changer. Dans un communiqué publié lundi soir, Spotify annonce trois nouveautés, dont la principale est Pick & Play : on peut chercher un morceau et lancer sa lecture. De même, on peut lancer le titre que l’on souhaite dans un album ou une liste. Ces possibilités en ouvrent une autre : on peut désormais partager un titre avec les comptes gratuits pour qu’ils puissent le lire directement. Cette fonction simple n’avait jamais été disponible jusqu’à présent, étant réservée aux abonnés payants.

Spotify ne lève cependant pas toutes les barrières, afin que les comptes gratuits et Premium ne soient pas séparés uniquement par la présence de publicités. Si vous ouvrez un album ou une liste, le titre choisi basculera automatiquement vers un autre morceau aléatoire une fois fini.

On peut se demander pourquoi Spotify se décide maintenant à lever ces blocages pour les comptes gratuits. L’entreprise suédoise en avait peut-être assez de voir les utilisateurs partir vers YouTube quand ils voulaient écouter une musique spécifique, car quitte à avoir une publicité, le service de Google permet effectivement de lancer n’importe quel contenu.

Ces fonctions en accompagnent également une autre lancée récemment : le mode Lossless pour les comptes Premium (disponible en France dans les semaines à venir). Spotify a peut-être décidé de lancer en peu de temps plusieurs fonctions qui lui étaient réclamées depuis longtemps, pour redorer un blason abimé par la problématique des musiques générées par IA.

Presque des PWA... mais non

La nouvelle mouture du navigateur embarque à son bord une capacité qui lui a été longtemps réclamée et que les navigateurs Chromium possèdent depuis des années (pour la plupart) : la possibilité d’épingler un site à la barre des tâches de Windows et de s’en servir comme d’une application web.

La fonction n’est disponible pour l’instant que sur le système de Microsoft et uniquement dans la version téléchargée sur le site de Mozilla, pas encore depuis le Store de Windows.

Pour s’en servir, il suffit de cliquer sur le nouveau bouton à droite de la barre des tâches, représentant une flèche vers le bas dans un rectangle. L’interface est alors réduite, avec une barre de titre plus simple, mais laissant toujours apparaitre le champ d’adresse. Firefox récupère simplement la favicon du site pour en faire l’icône dans la barre des tâches.

Contrairement au processus sur Chrome ou Edge, la fenêtre n’est pas vraiment considérée comme une application (PWA). On peut l’épingler à la barre des tâches, mais pas l’installer dans le menu Démarrer. Firefox ne possède pas non plus de liste des sites « installés » de cette manière.

Plusieurs autres modifications sont spécifiques à Windows. Par exemple, la compatibilité avec l’assistant Copilot, que l’on peut utiliser avec les autres dans la barre latérale, si elle est activée. Firefox 143 se rend également compatible avec l’automatisation de l’interface utilisateur Windows pour une meilleure accessibilité générale. Cet ajout doit simplifier l’utilisation d’outils intégrés comme le narrateur et le pilotage vocal.

Du neuf côté confidentialité

Parmi les autres nouveautés, citons la prévisualisation de l’image renvoyée par la caméra quand un site demande à s’en servir, toujours pratique. Une nouvelle option apparait également pour demander systématiquement si les téléchargements doivent être supprimés après une session de navigation privée. Sur Windows, macOS et Android, Firefox peut en outre lire les contenus xHE-AAC.

La barre d’adresse évolue pour afficher les dates importantes, mais uniquement aux États-Unis, au Royaume-Uni, en Allemagne, en France et en Italie. Pour les personnes utilisant les onglets verticaux, on peut aussi glisser-déposer les onglets dans le haut de la colonne pour les épingler plus facilement. Pendant la manipulation, cette zone s’éclaire en rose pour guider le geste.

Firefox renforce aussi sa protection contre les empreintes laissées par la navigation. Le navigateur va par exemple introduire des métadonnées aléatoires pour les images chargées afin que leur analyse par les sites ne serve pas au pistage. Firefox n’utilisera pas non plus les polices personnalisées installées sur l’ordinateur, uniquement celles fournies en standard par le système d’exploitation.

La version Android évolue également, avec notamment l’affichage de la progression des téléchargements avec des boutons d’actions (pause, reprendre, annuler, recommencer), ou encore la possibilité de configurer DNS over HTTPS depuis les paramètres du navigateur.

Enfin, le nouveau Firefox colmate 11 brèches de sécurité, dont 3 critiques. Comme toujours, il est recommandé d’installer rapidement la mise à jour. Sur ordinateur, il suffit le plus souvent de redémarrer le navigateur.

Presque des PWA... mais non

La nouvelle mouture du navigateur embarque à son bord une capacité qui lui a été longtemps réclamée et que les navigateurs Chromium possèdent depuis des années (pour la plupart) : la possibilité d’épingler un site à la barre des tâches de Windows et de s’en servir comme d’une application web.

La fonction n’est disponible pour l’instant que sur le système de Microsoft et uniquement dans la version téléchargée sur le site de Mozilla, pas encore depuis le Store de Windows.

Pour s’en servir, il suffit de cliquer sur le nouveau bouton à droite de la barre des tâches, représentant une flèche vers le bas dans un rectangle. L’interface est alors réduite, avec une barre de titre plus simple, mais laissant toujours apparaitre le champ d’adresse. Firefox récupère simplement la favicon du site pour en faire l’icône dans la barre des tâches.

Contrairement au processus sur Chrome ou Edge, la fenêtre n’est pas vraiment considérée comme une application (PWA). On peut l’épingler à la barre des tâches, mais pas l’installer dans le menu Démarrer. Firefox ne possède pas non plus de liste des sites « installés » de cette manière.

Plusieurs autres modifications sont spécifiques à Windows. Par exemple, la compatibilité avec l’assistant Copilot, que l’on peut utiliser avec les autres dans la barre latérale, si elle est activée. Firefox 143 se rend également compatible avec l’automatisation de l’interface utilisateur Windows pour une meilleure accessibilité générale. Cet ajout doit simplifier l’utilisation d’outils intégrés comme le narrateur et le pilotage vocal.

Du neuf côté confidentialité

Parmi les autres nouveautés, citons la prévisualisation de l’image renvoyée par la caméra quand un site demande à s’en servir, toujours pratique. Une nouvelle option apparait également pour demander systématiquement si les téléchargements doivent être supprimés après une session de navigation privée. Sur Windows, macOS et Android, Firefox peut en outre lire les contenus xHE-AAC.

La barre d’adresse évolue pour afficher les dates importantes, mais uniquement aux États-Unis, au Royaume-Uni, en Allemagne, en France et en Italie. Pour les personnes utilisant les onglets verticaux, on peut aussi glisser-déposer les onglets dans le haut de la colonne pour les épingler plus facilement. Pendant la manipulation, cette zone s’éclaire en rose pour guider le geste.

Firefox renforce aussi sa protection contre les empreintes laissées par la navigation. Le navigateur va par exemple introduire des métadonnées aléatoires pour les images chargées afin que leur analyse par les sites ne serve pas au pistage. Firefox n’utilisera pas non plus les polices personnalisées installées sur l’ordinateur, uniquement celles fournies en standard par le système d’exploitation.

La version Android évolue également, avec notamment l’affichage de la progression des téléchargements avec des boutons d’actions (pause, reprendre, annuler, recommencer), ou encore la possibilité de configurer DNS over HTTPS depuis les paramètres du navigateur.

Enfin, le nouveau Firefox colmate 11 brèches de sécurité, dont 3 critiques. Comme toujours, il est recommandé d’installer rapidement la mise à jour. Sur ordinateur, il suffit le plus souvent de redémarrer le navigateur.

Les Acts restent

Le Data Act est désormais en application. Avec lui, l’Europe veut transformer la chaine de valeur des données, tout en les libérant. De grandes ambitions, alors que les données sont devenues extrêmement précieuses depuis l’explosion de l’IA. Pour les entreprises, cela doit signaler en outre une simplification dans la gestion de leurs informations entre les prestataires de cloud.

Le Data Act, voté en 2023, est entré en vigueur le 11 janvier 2024 et en application le 12 septembre. Il affiche plusieurs grands objectifs : veiller à ce que les appareils connectés en Union européenne puissent partager leurs données, offrir aux consommateurs plus de possibilités sur le choix des prestataires ou réparateurs en fonction de ces informations, permettre aux industries de récupérer les données présentes dans les équipements spécialisés, laisser les clients changer de fournisseur cloud plus facilement, et enfin interdire les contrats qui pourraient empêcher les partages de données. Pour les particuliers, il s’applique notamment à tout le secteur de l’IoT.

« Le règlement sur les données est conçu pour responsabiliser les utilisateurs, tant les consommateurs que les entreprises, en leur donnant un plus grand contrôle sur les données générées par leurs appareils connectés, tels que les voitures, les téléviseurs intelligents et les machines industrielles. Il jette les bases d’une économie européenne des données équitable, innovante et compétitive », indique la Commission européenne.

Jusqu’à présent, il a surtout été fait référence au Data Act pour sa capacité à chambouler le marché du cloud. Depuis son entrée en application, il est censé empêcher les grandes entreprises de pratiquer des tarifs de sortie des données (egress fees). La volonté de l’Union dans ce domaine est claire : empêcher la rétention des données. Le texte est cependant plus large et induit un changement de paradigme.

Toutes les données non personnelles

Le texte aborde de nombreux autres points et vient s’articuler avec le RGPD, qu’il complète en visant les données non personnelles. Il est possible que les deux règlements entrent en conflit sur des sujets spécifiques, auquel cas le RGPD l’emporte systématiquement, précisait déjà la Commission européenne dans une FAQ publiée en septembre 2024. De même, les autorités de protection des données (comme la CNIL en France) conservent leurs compétences et le Data Act ne remplace pas les législations sectorielles existantes.

Le texte ne vise pas l’intégralité des données. Dans le cadre des objets connectés, de l’industrie ou encore de l’agriculture, il concerne les informations brutes ou pré-traitées. Les données dérivées ou inférées (dans le cadre d’un traitement de type IA) ne sont pas incluses. De très nombreuses catégories de produits sont concernées, jusqu’à la domotique. L’électroménager dit « intelligent » dispose ainsi, par exemple, de données d’utilisation que les utilisateurs européens peuvent vouloir récupérer. Il y a deux conditions : que l’utilisateur dispose d’un droit stable sur le produit (propriétaire ou contractuel de location/bail) et que le produit soit commercialisé dans l’Union européenne.

Le Data Act précise également que ces données doivent être fournies dans un format structuré, couramment utilisé et lisible par machine, avec une qualité équivalente à celle utilisée par le détenteur pour ses propres besoins. La disponibilité en temps réel est requise lorsque cela est pertinent et techniquement réalisable.

Avant même qu’une telle opération prenne place, toutes les entreprises concernées doivent informer leurs clients que cette possibilité existe, et leurs modalités d’accès. Les entreprises peuvent refuser dans deux types de cas : quand la communication des données risque de compromettre la confidentialité des secrets commerciaux ou quand elle pourrait affecter la sécurité des produits. Dans ces cas, elles doivent contacter les autorités compétentes pour les informer, avant d’avertir les utilisateurs. Ces derniers peuvent contester ces conditions devant des tribunaux, les autorités compétentes ou des organismes de règlement des différends.

À noter que si le règlement s’applique à toutes les données non personnelles, certaines catégories spécifiques sont exclues. C’est notamment le cas des infrastructures (routes, aéroports, chemins de fer), des prototypes ainsi que des produits destinés au stockage et/ou au traitement des données.

Le cœur du Data Act

Sans agence, sans Looping

Au cours des derniers mois, la gestion des mises à jour de sécurité a évolué chez Google. Désormais, elle est basée sur une évaluation des risques, avec une priorité donnée aux failles présentant un risque accru. Pour le reste, la diffusion des correctifs adopte un rythme davantage trimestriel. Il semble que le changement ait été mis en place pour soulager les constructeurs.

Le changement a été révélé par Android Authority le 13 septembre et confirmé à demi-mot par Google. Nos confrères relèvent ainsi que le bulletin de juillet ne contenait aucune vulnérabilité corrigée, une rupture face aux 120 failles corrigées depuis le début de l’année. À l’inverse, le bulletin de septembre comportait des correctifs pour 119 failles à lui seul. Comment expliquer une telle différence ?

Une évaluation des risques

Google donne à présent la priorité aux failles comportant un risque élevé, qui ne tient pas uniquement compte de la criticité d’une vulnérabilité. L’entreprise ne détaille pas les critères d’évaluation, mais on peut supposer que le nombre de cibles potentielles et la facilité de mise en œuvre font partie des principaux, de même que l’existence d’une exploitation connue. Selon Android Authority, le mécanisme est nommé Risk-Based Update System, ou RBUS.

La règle est simple : si la faille présente un risque élevé, elle est publiée comme telle dans le bulletin mensuel, et si elle peut attendre, elle partira dans le bulletin trimestriel. Pour nos confrères, ce changement a été mis en place pour soulager les constructeurs intégrant Android dans leurs smartphones (OEM). Les failles à haut risque ont ainsi des chances accrues d’avoir un correctif rapidement diffusé, la diffusion des solutions étant parfois complexe à maintenir en fonction du nombre d’appareils concernés.

Toujours selon Android Authority, ce changement explique pourquoi le bulletin de juillet était vide : aucune faille à haut risque n’était répertoriée. Il explique aussi celui de septembre comptait autant de failles corrigées : elles avaient toutes été mises de côté pour le grand bulletin trimestriel.

Avantages et inconvénients

Bien que Google n’ait pas documenté ce changement, la société l’a confirmé à demi-mots à Android Authority :

« Les bulletins de sécurité Android et Pixel sont publiés tous les mois. Pour assurer la sécurité des utilisateurs, nous intégrons une sécurité puissante profondément ancrée dans les fondations d’Android. Android arrête la plupart des exploitations de vulnérabilité à la source grâce à un renforcement complet de la plate-forme, comme notre utilisation du langage Rust et des protections anti-exploitation avancées. Android et Pixel corrigent en permanence les failles de sécurité connues et donnent la priorité à la correction des vulnérabilités les plus risquées en premier »

Côté utilisateurs, rien ne change vraiment dans la plupart des cas. Les constructeurs décidant d’appliquer quand même les correctifs de sécurité tous les mois pourront continuer à le faire. Ceux souhaitant un rythme plus souple ne diffuseront alors des correctifs mensuels que si des failles à haut risque y sont présentes, et se contenteront d’une grosse mise à jour tous les trois mois dans le cas contraire.

Les avantages ne concernent a priori que les OEM, qui ont parfois du mal à tenir le rythme, selon les gammes commercialisées et le nombre de modifications faites sur la base d’Android. En leur offrant un nouveau cycle trimestriel, ils peuvent en théorie mieux préparer le terrain.

L’approche a également ses inconvénients. Retarder la publication des mises à jour peut laisser le temps à certaines failles d’être exploitées. Car les informations circulent : si des failles sont trouvées, les entreprises sont averties, de même que les équipes d’ingénieurs. Plus il y a de personnes au courant, plus le risque de fuite augmente, et avec lui la probabilité d’une exploitation.

Un système complexe

Le problème des mises à jour de sécurité sur Android est débattu depuis longtemps, avec toujours le même constat : les constructeurs doivent jouer le jeu. La pluralité des gammes et le nombre de modifications apportées à la base d’Android peuvent ralentir l’application des correctifs, car il faut mener suffisamment de tests pour s’assurer du bon fonctionnement. Plus il y a d’appareils dans les gammes, plus ce travail est conséquent.

Comme le rappelle d’ailleurs Android Authority, les entreprises ne jouent pas toutes le jeu de la même manière. Si l’on voit depuis deux ans des annonces très importantes sur la durée du support, notamment sur les Pixel et les Galaxy S de Samsung, un bon support est trop souvent dépendant de la gamme. De nombreux appareils d’entrée ou milieu de gamme ont un support limité de quelques années, les correctifs de sécurité n’arrivant pas tous les mois. C’est d’ailleurs ce qui a poussé l’Union européenne à imposer un nouveau minimum de cinq ans pour les mises à jour logicielles sur tous les nouveaux appareils.

• Smartphones, tablettes : l’étiquette énergie et l’écoconception entrent en application

Google connait bien le problème. Le projet Mainline (initié avec Android 10, mais arrivé concrètement dans les versions suivantes) a notamment été instauré pour augmenter le nombre de composants pouvant être mis à jour directement par Google Play. Mais de nombreux composants bas niveau ne peuvent être modifiés que par les constructeurs. Aussi, lorsque Google signale une faille et prépare une modification de code, celle-ci n’est pas publiée immédiatement dans AOSP (Android Open Source Project), pour que les modifications de code ne révèlent pas les détails de la brèche.

Le nouveau mécanisme ne remet pas en cause l’Android Security Bulletin mensuel. L’ASB dispose pour rappel de deux versions : une publique pour lister les failles corrigées, et une privée pour avertir les OEM un mois avant et leur laisser d’intégrer les correctifs. En revanche, certains bulletins seront parfois vides, qu’ils soient publics ou privés. Les bulletins complets seront désormais alignés sur le rythme trimestriel d’Android depuis sa dernière version 16.

Sans agence, sans Looping

Au cours des derniers mois, la gestion des mises à jour de sécurité a évolué chez Google. Désormais, elle est basée sur une évaluation des risques, avec une priorité donnée aux failles présentant un risque accru. Pour le reste, la diffusion des correctifs adopte un rythme davantage trimestriel. Il semble que le changement ait été mis en place pour soulager les constructeurs.

Le changement a été révélé par Android Authority le 13 septembre et confirmé à demi-mot par Google. Nos confrères relèvent ainsi que le bulletin de juillet ne contenait aucune vulnérabilité corrigée, une rupture face aux 120 failles corrigées depuis le début de l’année. À l’inverse, le bulletin de septembre comportait des correctifs pour 119 failles à lui seul. Comment expliquer une telle différence ?

Une évaluation des risques

Google donne à présent la priorité aux failles comportant un risque élevé, qui ne tient pas uniquement compte de la criticité d’une vulnérabilité. L’entreprise ne détaille pas les critères d’évaluation, mais on peut supposer que le nombre de cibles potentielles et la facilité de mise en œuvre font partie des principaux, de même que l’existence d’une exploitation connue. Selon Android Authority, le mécanisme est nommé Risk-Based Update System, ou RBUS.

La règle est simple : si la faille présente un risque élevé, elle est publiée comme telle dans le bulletin mensuel, et si elle peut attendre, elle partira dans le bulletin trimestriel. Pour nos confrères, ce changement a été mis en place pour soulager les constructeurs intégrant Android dans leurs smartphones (OEM). Les failles à haut risque ont ainsi des chances accrues d’avoir un correctif rapidement diffusé, la diffusion des solutions étant parfois complexe à maintenir en fonction du nombre d’appareils concernés.

Toujours selon Android Authority, ce changement explique pourquoi le bulletin de juillet était vide : aucune faille à haut risque n’était répertoriée. Il explique aussi celui de septembre comptait autant de failles corrigées : elles avaient toutes été mises de côté pour le grand bulletin trimestriel.

Avantages et inconvénients

Bien que Google n’ait pas documenté ce changement, la société l’a confirmé à demi-mots à Android Authority :

« Les bulletins de sécurité Android et Pixel sont publiés tous les mois. Pour assurer la sécurité des utilisateurs, nous intégrons une sécurité puissante profondément ancrée dans les fondations d’Android. Android arrête la plupart des exploitations de vulnérabilité à la source grâce à un renforcement complet de la plate-forme, comme notre utilisation du langage Rust et des protections anti-exploitation avancées. Android et Pixel corrigent en permanence les failles de sécurité connues et donnent la priorité à la correction des vulnérabilités les plus risquées en premier »

Côté utilisateurs, rien ne change vraiment dans la plupart des cas. Les constructeurs décidant d’appliquer quand même les correctifs de sécurité tous les mois pourront continuer à le faire. Ceux souhaitant un rythme plus souple ne diffuseront alors des correctifs mensuels que si des failles à haut risque y sont présentes, et se contenteront d’une grosse mise à jour tous les trois mois dans le cas contraire.

Les avantages ne concernent a priori que les OEM, qui ont parfois du mal à tenir le rythme, selon les gammes commercialisées et le nombre de modifications faites sur la base d’Android. En leur offrant un nouveau cycle trimestriel, ils peuvent en théorie mieux préparer le terrain.

L’approche a également ses inconvénients. Retarder la publication des mises à jour peut laisser le temps à certaines failles d’être exploitées. Car les informations circulent : si des failles sont trouvées, les entreprises sont averties, de même que les équipes d’ingénieurs. Plus il y a de personnes au courant, plus le risque de fuite augmente, et avec lui la probabilité d’une exploitation.

Un système complexe

Le problème des mises à jour de sécurité sur Android est débattu depuis longtemps, avec toujours le même constat : les constructeurs doivent jouer le jeu. La pluralité des gammes et le nombre de modifications apportées à la base d’Android peuvent ralentir l’application des correctifs, car il faut mener suffisamment de tests pour s’assurer du bon fonctionnement. Plus il y a d’appareils dans les gammes, plus ce travail est conséquent.

Comme le rappelle d’ailleurs Android Authority, les entreprises ne jouent pas toutes le jeu de la même manière. Si l’on voit depuis deux ans des annonces très importantes sur la durée du support, notamment sur les Pixel et les Galaxy S de Samsung, un bon support est trop souvent dépendant de la gamme. De nombreux appareils d’entrée ou milieu de gamme ont un support limité de quelques années, les correctifs de sécurité n’arrivant pas tous les mois. C’est d’ailleurs ce qui a poussé l’Union européenne à imposer un nouveau minimum de cinq ans pour les mises à jour logicielles sur tous les nouveaux appareils.

• Smartphones, tablettes : l’étiquette énergie et l’écoconception entrent en application

Google connait bien le problème. Le projet Mainline (initié avec Android 10, mais arrivé concrètement dans les versions suivantes) a notamment été instauré pour augmenter le nombre de composants pouvant être mis à jour directement par Google Play. Mais de nombreux composants bas niveau ne peuvent être modifiés que par les constructeurs. Aussi, lorsque Google signale une faille et prépare une modification de code, celle-ci n’est pas publiée immédiatement dans AOSP (Android Open Source Project), pour que les modifications de code ne révèlent pas les détails de la brèche.

Le nouveau mécanisme ne remet pas en cause l’Android Security Bulletin mensuel. L’ASB dispose pour rappel de deux versions : une publique pour lister les failles corrigées, et une privée pour avertir les OEM un mois avant et leur laisser d’intégrer les correctifs. En revanche, certains bulletins seront parfois vides, qu’ils soient publics ou privés. Les bulletins complets seront désormais alignés sur le rythme trimestriel d’Android depuis sa dernière version 16.

Apple a ouvert grand les vannes lundi pour les versions 26 de toutes ses plateformes. Dans le même temps, l’entreprise a lancé de nouvelles mises à jour intermédiaires pour les moutures précédentes.

iOS/iPadOS 18.7 et macOS 15.7 ont été mis à disposition en même temps que les versions majeures hier soir. Dans l’interface de mise à jour sur iOS, cette version apparaissait même avant la mouture 26. Elles ont été publiées pour colmater une série de failles de sécurité, dont on trouve la liste sur le site d’Apple. Les correctifs concernent des composants comme CoreAudio, le noyau, libc, MobileStorageMounter, Raccourcis ou encore WebKit.

Apple a également publié des mises à jour de sécurité pour des versions plus anciennes de ses systèmes. Pour iOS/iPadOS, on trouve ainsi les versions 15.8.5 et 16.7.12. Sur Mac, les machines sous Sonoma reçoivent la 14.8.

S’agissant de correctifs de sécurité, il est conseillé d’appliquer rapidement les mises à jour, qui réclament un redémarrage.

Apple a ouvert grand les vannes lundi pour les versions 26 de toutes ses plateformes. Dans le même temps, l’entreprise a lancé de nouvelles mises à jour intermédiaires pour les moutures précédentes.

iOS/iPadOS 18.7 et macOS 15.7 ont été mis à disposition en même temps que les versions majeures hier soir. Dans l’interface de mise à jour sur iOS, cette version apparaissait même avant la mouture 26. Elles ont été publiées pour colmater une série de failles de sécurité, dont on trouve la liste sur le site d’Apple. Les correctifs concernent des composants comme CoreAudio, le noyau, libc, MobileStorageMounter, Raccourcis ou encore WebKit.

Apple a également publié des mises à jour de sécurité pour des versions plus anciennes de ses systèmes. Pour iOS/iPadOS, on trouve ainsi les versions 15.8.5 et 16.7.12. Sur Mac, les machines sous Sonoma reçoivent la 14.8.

S’agissant de correctifs de sécurité, il est conseillé d’appliquer rapidement les mises à jour, qui réclament un redémarrage.

Comme prévu, Apple commence la diffusion des versions finales pour ses nouvelles plateformes. Elles sont toutes estampillées 26, afin d’harmoniser les numéros entre les systèmes, Apple prenant pour référence l’année à venir. iOS passe ainsi de la version 18 à la 26.

La nouveauté la plus visible et commune à toutes les plateformes est la nouvelle interface Liquid Glass, qui a fait couler beaucoup d’encre. Apple sort de sa période « flat » sobre pour tenter l’aventure du verre plus ou moins dépoli, avec de nombreux effets liés. Liquid Glass a été largement critiquée pendant la phase bêta pour des problèmes de lisibilité et d’accessibilité, mais elle semble là pour durer. On pourrait faire un parallèle avec iOS 7 et la première incarnation du flat design chez Apple, qui avait défrayé la chronique en son temps.

iOS 26 introduit notamment une nouvelle application Téléphone, qui permet de mieux gérer l’historique des appels. Elle peut regrouper les appels en absence et peut filtrer automatiquement tous ceux en provenance de numéros inconnus, avec plusieurs possibilités. On peut choisir par exemple de les envoyer directement sur le répondeur. Citons également l’alimentation adaptative, des informations beaucoup plus détaillées sur l’autonomie, les applications Aperçu et Jeux vidéo, de la personnalisation dans Messages, la traduction automatique des paroles dans Music, etc.

iPadOS 26 récupère ces apports et en ajoute d’autres. La nouvelle version est réellement majeure : toutes les applications peuvent passer sous forme de fenêtre via un glissement sur leur coin inférieur droit. On peut alors les déplacer librement, la contrôler via les trois boutons colorés typiques de macOS, utiliser la barre de menus, agencer les fenêtres via des options de tiling et profiter de la vue Exposé.

macOS 26, nommé Tahoe, reprend l’application Téléphone complète, en lieu et place de FaceTime. Surtout, Spotlight et Raccourcis font leur petite révolution. Le premier devient une palette complète de commandes, avec possibilité de créer des raccourcis personnalisés et de reprendre les actions suggérées par Apple Intelligence. Idem pour Raccourcis, qui peut maintenant agir sur un plus grand nombre d’objets. Toutes les actions liées au bouquet IA lui sont également accessibles. Par exemple, si Apple Intelligence détecte qu’une transcription a souvent lieu après avoir enregistré l’audio d’un cours, Raccourcis pourra suggérer une action pour enchainer automatiquement les actions, avec export et envoi du document sur une destination choisie.

Quant à watchOS et tvOS, leurs nouveautés sont plus discrètes. Pour la montre connectée, on peut noter Workout Buddy, censé encourager dans la pratique sportive, l’arrivée de Notes, des suggestions d’activités et de listes musicales ou encore une révision des notifications, qui se veulent moins intrusives.

Comme prévu, Apple commence la diffusion des versions finales pour ses nouvelles plateformes. Elles sont toutes estampillées 26, afin d’harmoniser les numéros entre les systèmes, Apple prenant pour référence l’année à venir. iOS passe ainsi de la version 18 à la 26.

La nouveauté la plus visible et commune à toutes les plateformes est la nouvelle interface Liquid Glass, qui a fait couler beaucoup d’encre. Apple sort de sa période « flat » sobre pour tenter l’aventure du verre plus ou moins dépoli, avec de nombreux effets liés. Liquid Glass a été largement critiquée pendant la phase bêta pour des problèmes de lisibilité et d’accessibilité, mais elle semble là pour durer. On pourrait faire un parallèle avec iOS 7 et la première incarnation du flat design chez Apple, qui avait défrayé la chronique en son temps.

iOS 26 introduit notamment une nouvelle application Téléphone, qui permet de mieux gérer l’historique des appels. Elle peut regrouper les appels en absence et peut filtrer automatiquement tous ceux en provenance de numéros inconnus, avec plusieurs possibilités. On peut choisir par exemple de les envoyer directement sur le répondeur. Citons également l’alimentation adaptative, des informations beaucoup plus détaillées sur l’autonomie, les applications Aperçu et Jeux vidéo, de la personnalisation dans Messages, la traduction automatique des paroles dans Music, etc.

iPadOS 26 récupère ces apports et en ajoute d’autres. La nouvelle version est réellement majeure : toutes les applications peuvent passer sous forme de fenêtre via un glissement sur leur coin inférieur droit. On peut alors les déplacer librement, la contrôler via les trois boutons colorés typiques de macOS, utiliser la barre de menus, agencer les fenêtres via des options de tiling et profiter de la vue Exposé.

macOS 26, nommé Tahoe, reprend l’application Téléphone complète, en lieu et place de FaceTime. Surtout, Spotlight et Raccourcis font leur petite révolution. Le premier devient une palette complète de commandes, avec possibilité de créer des raccourcis personnalisés et de reprendre les actions suggérées par Apple Intelligence. Idem pour Raccourcis, qui peut maintenant agir sur un plus grand nombre d’objets. Toutes les actions liées au bouquet IA lui sont également accessibles. Par exemple, si Apple Intelligence détecte qu’une transcription a souvent lieu après avoir enregistré l’audio d’un cours, Raccourcis pourra suggérer une action pour enchainer automatiquement les actions, avec export et envoi du document sur une destination choisie.

Quant à watchOS et tvOS, leurs nouveautés sont plus discrètes. Pour la montre connectée, on peut noter Workout Buddy, censé encourager dans la pratique sportive, l’arrivée de Notes, des suggestions d’activités et de listes musicales ou encore une révision des notifications, qui se veulent moins intrusives.

Linux Mint 22.2, alias Zara, est sortie il y a moins de deux semaines, apportant avec elle le support des empreintes digitales pour l’authentification, une meilleure prise en charge de libadwaita ainsi qu’une série d’améliorations visuelles.

• Linux Mint 22.2 supporte mieux libadwaita et les empreintes digitales

On sait désormais que la prochaine version, estampillée 22.3, est prévue pour décembre. L’annonce a été faite par Clément Lefebvre (créateur de Linux Mint et développeur principal) dans sa lettre mensuelle. La mouture proposera notamment le nouveau menu principal pour Cinnamon, comme nous l’indiquions en mars. On y trouvera également un nouvel applet d’état et le support de Wayland pour les dispositions de claviers et autres méthodes de saisie.

Pour une partie des utilisateurs, c’est surtout la Linux Mint Debian Edition 7 (LMDE 7) qui est attendue. La bêta est attendue avant la fin du mois et est donc imminente. Le système sera basé sur Debian 13 (« Trixie ») et représentera donc une vaste modernisation. L’équipe de développement lui ajoutera les dernières améliorations vues sur Linux Mint 22.2.

Cette Debian Edition 7 n’existera qu’en version amd64, l’équipe de Mint suivant la disparition du i386 sur Debian. Il faut également noter que si Mint reprend le socle Debian tel qu’il est actuellement, alors LMDE 7 sera fourni avec un noyau Linux 6.12 (LTS), soit une version moins récente que la 6.14 de Linux Mint 22.3.

Linux Mint 22.2, alias Zara, est sortie il y a moins de deux semaines, apportant avec elle le support des empreintes digitales pour l’authentification, une meilleure prise en charge de libadwaita ainsi qu’une série d’améliorations visuelles.

• Linux Mint 22.2 supporte mieux libadwaita et les empreintes digitales

On sait désormais que la prochaine version, estampillée 22.3, est prévue pour décembre. L’annonce a été faite par Clément Lefebvre (créateur de Linux Mint et développeur principal) dans sa lettre mensuelle. La mouture proposera notamment le nouveau menu principal pour Cinnamon, comme nous l’indiquions en mars. On y trouvera également un nouvel applet d’état et le support de Wayland pour les dispositions de claviers et autres méthodes de saisie.

Pour une partie des utilisateurs, c’est surtout la Linux Mint Debian Edition 7 (LMDE 7) qui est attendue. La bêta est attendue avant la fin du mois et est donc imminente. Le système sera basé sur Debian 13 (« Trixie ») et représentera donc une vaste modernisation. L’équipe de développement lui ajoutera les dernières améliorations vues sur Linux Mint 22.2.

Cette Debian Edition 7 n’existera qu’en version amd64, l’équipe de Mint suivant la disparition du i386 sur Debian. Il faut également noter que si Mint reprend le socle Debian tel qu’il est actuellement, alors LMDE 7 sera fourni avec un noyau Linux 6.12 (LTS), soit une version moins récente que la 6.14 de Linux Mint 22.3.

Interface chaise-clavier

Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Elle est qualifiée désormais de plus grande attaque contre la chaine d’approvisionnement jamais enregistrée. Une telle attaque consiste pour rappel à viser la chaine menant à la production d’un logiciel ou d’un service. Si elle aboutit, un code se retrouve distribué ou mis à disposition des victimes, qui croient récupérer un logiciel, la dernière version d’un composant, etc. Elle permet d’arroser un nombre important de personnes, d’autant plus que le composant ou logiciel est populaire.

Dans l’après-midi du lundi 8 septembre, des pirates ont ainsi compromis le compte NPM (Node Packet Manager, gestionnaire de paquet par défaut pour Node.js) d’un développeur. La récupération des accès leur a permis d’infecter le code de 18 paquets : backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles.

Certains sont téléchargés des centaines de millions de fois par semaine. Pourtant, tout a été réglé en deux heures environ et la casse a été limitée. Que s’est-il passé ?

L’ingénierie sociale, toujours elle

L’histoire commence avec une détection de l’entreprise belge Aikido. Elle est spécialisée dans la sécurité, et plus particulièrement dans la surveillance des mises à jour de code dans les principaux dépôts open source. Comme elle raconte dans un billet de blog, elle détecte le 8 septembre à 15h16 (heure de Paris) des modifications suspicieuses dans 18 paquets. Ils sont très populaires sur NPM : ensemble, ils cumulent deux milliards de téléchargements par semaine.

L’analyse du code révèle sa fonction : intercepter silencieusement l’activité crypto et web3 dans le navigateur, manipuler les interactions avec le portefeuille et rediriger les paiements vers des comptes contrôlés par les pirates. Le code malveillant peut détourner à la fois le trafic réseau et les API des applications, indique Aikido. « Ce qui le rend dangereux, c’est qu’il fonctionne à plusieurs niveaux : modifier le contenu affiché sur les sites Web, falsifier les appels API et manipuler ce que les applications des utilisateurs croient signer », ajoute l’entreprise.

La société belge indique avoir alors contacté le développeur concerné, Josh Junon, surnommé Qix. Celui-ci répond alors qu’il a découvert avoir été piraté. Comme il l’indique lui-même dans un message sur BlueSky deux heures plus tard, il dit avoir été victime d’un email qui l’invitait à réinitialiser ses codes d’authentification à deux facteurs (2FA). Le courrier semblait parfaitement légitime selon lui, avec un lien renvoyant vers une copie conforme de la page de connexion de NPM. Cette page interceptait les informations d’authentification et le jeton 2FA pour les envoyer aux pirates. Après quoi, ces derniers ont simplement modifié l’adresse de connexion utilisée pour se connecter à NPM.

Le 9 septembre, Josh Junon a publié un message d’excuses sur Hacker News, dans lequel il admet honteusement : « yep I got pwned ». Le même jour, jFrog indiquait de son côté que la campagne continuait et que de nouveaux paquets contaminés avaient été découverts, dont DuckDB. Toujours le 9 septembre, SlowMist avertissait que d’autres développeurs recevaient le même e-mail, signe que Josh Junon n’était pas un cas isolé.

Tout s’enchaine très vite

Une chaine d’approvisionnement contaminée sur des paquets aussi populaires aurait constitué une catastrophe pour de nombreux produits. Ces attaques sont notamment très efficaces contre des composants impliqués dans le web de manière générale. Or, avec la multiplication des applications web encapsulées, cela pouvait signifier une diffusion à très grande échelle du code vérolé. Pourtant, tout s’est achevé en quelques heures, sans grande casse.

Sur le blog de la Security Alliance, on peut lire dans le billet du 9 septembre une note ironisant sur les 5 cents d’ETH ou encore les 20 dollars d’un memecoin. Dans les heures qui ont suivi la compromission, seuls 588 dollars de transactions auraient été détectés. Ce qui fait dire à l’Alliance que le plus gros impact financier de l’attaque réside finalement dans « les milliers d’heures passées collectivement par les équipes d’ingénierie et de sécurité du monde entier à nettoyer les environnements compromis, et les millions de dollars de contrats de vente qui seront inévitablement signés à la suite de cette nouvelle étude de cas ».

Cité par Brian Krebs, le pentester Philippe Catureli, responsable sécurité chez Seralys, s’en étonne également : « Ce qui est fou, c’est qu’ils ont compromis des milliards de sites Web et d’applications juste pour cibler quelques crypto-monnaies. Il s’agissait d’une attaque de la chaîne d’approvisionnement, et cela aurait facilement pu être quelque chose de bien pire que la récolte de crypto-monnaies ».

Même son de cloche chez Florian Roth, chercheur en sécurité chez Nextron Systems : « Étant donné que la plupart des entreprises exécutent au moins une application React ou Angular, elles ont eu la possibilité d’exécuter du code sur des millions de systèmes dans des milliers d’organisations. Et ils l’ont utilisé pour lacher un voleur de cryptomonnaies obscurci de manière amateur, ont été attrapés par des règles élémentaires de détection, et le problème a été résolu après 2 heures ». Pas mieux du côté du chercheur Kevin Beaumont.

L’authentification des développeurs à nouveau en question

Dans son billet de blog, Aikido relève également le vaste danger évité de peu. De faibles conséquences qui ne semblent dues qu’au manque de compétences des pirates, en dépit de leur réussite sur la chaine d’approvisionnement.

Pour montrer à quel point ce type d’incident peut être grave, la société belge rappelle une autre compromission qui s’est déroulée fin août. Là aussi, un autre développeur NPM avait été visé, permettant la récupération de ses identifiants et l’insertion d’un code malveillant dans nx, une boite à outils pour le développement open source, totalisant six millions de téléchargements par semaine.

Le code malveillant avait servi à analyser l’ordinateur du développeur pour y récupérer des jetons d’authentification, ainsi que des clés SSH et API. Ces informations n’ont cependant pas été transmises aux pirates : elles ont été publiées dans un référentiel public créé pour l’occasion dans le compte GitHub du développeur, afin qu’elles soient visibles de tous et téléchargeables.

À Brian Krebs, Charlie Eriksen, chercheur chez Aikido, affirme que tous les paquets les plus populaires devraient exiger des attestations pour les modifications de code. De manière plus générale, il est d’avis que des plateformes comme GitHub et NPM devraient relever le niveau de sécurité, en s’assurant que les commits (une proposition de modification du code, pour schématiser) sont proposés par des personnes étant bien qui elles prétendent être.

S’il s’en est fallu de peu pour échapper à une catastrophe, les évènements ne semblent pas avoir surpris les chercheurs en sécurité, qui répètent les mêmes éléments depuis des années. Kevin Beaumont s’en moquait justement avec acidité, rappelant – encore une fois – que certaines des briques logicielles les plus utilisées ne sont gérées que par une poignée de personnes. Renvoyant une fois de plus au célèbre dessin de xkcd sur les dépendances.

Rappelons également que l’authentification à facteurs multiples, si elle apporte un gain majeur de protection, n’est pas absolue. En août 2022, Microsoft avait expliqué en détail par exemple comment un acteur malveillant avait mis en place toute une infrastructure pour récupérer des jetons d’authentification, via notamment des serveurs mimant un comportement légitime. Ce type d’attaque passe systématiquement par la compromission d’une personne, le plus souvent par un e-mail soigneusement préparé.

Interface chaise-clavier

Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Elle est qualifiée désormais de plus grande attaque contre la chaine d’approvisionnement jamais enregistrée. Une telle attaque consiste pour rappel à viser la chaine menant à la production d’un logiciel ou d’un service. Si elle aboutit, un code se retrouve distribué ou mis à disposition des victimes, qui croient récupérer un logiciel, la dernière version d’un composant, etc. Elle permet d’arroser un nombre important de personnes, d’autant plus que le composant ou logiciel est populaire.

Dans l’après-midi du lundi 8 septembre, des pirates ont ainsi compromis le compte NPM (Node Packet Manager, gestionnaire de paquet par défaut pour Node.js) d’un développeur. La récupération des accès leur a permis d’infecter le code de 18 paquets : backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles.

Certains sont téléchargés des centaines de millions de fois par semaine. Pourtant, tout a été réglé en deux heures environ et la casse a été limitée. Que s’est-il passé ?

L’ingénierie sociale, toujours elle

L’histoire commence avec une détection de l’entreprise belge Aikido. Elle est spécialisée dans la sécurité, et plus particulièrement dans la surveillance des mises à jour de code dans les principaux dépôts open source. Comme elle raconte dans un billet de blog, elle détecte le 8 septembre à 15h16 (heure de Paris) des modifications suspicieuses dans 18 paquets. Ils sont très populaires sur NPM : ensemble, ils cumulent deux milliards de téléchargements par semaine.

L’analyse du code révèle sa fonction : intercepter silencieusement l’activité crypto et web3 dans le navigateur, manipuler les interactions avec le portefeuille et rediriger les paiements vers des comptes contrôlés par les pirates. Le code malveillant peut détourner à la fois le trafic réseau et les API des applications, indique Aikido. « Ce qui le rend dangereux, c’est qu’il fonctionne à plusieurs niveaux : modifier le contenu affiché sur les sites Web, falsifier les appels API et manipuler ce que les applications des utilisateurs croient signer », ajoute l’entreprise.

La société belge indique avoir alors contacté le développeur concerné, Josh Junon, surnommé Qix. Celui-ci répond alors qu’il a découvert avoir été piraté. Comme il l’indique lui-même dans un message sur BlueSky deux heures plus tard, il dit avoir été victime d’un email qui l’invitait à réinitialiser ses codes d’authentification à deux facteurs (2FA). Le courrier semblait parfaitement légitime selon lui, avec un lien renvoyant vers une copie conforme de la page de connexion de NPM. Cette page interceptait les informations d’authentification et le jeton 2FA pour les envoyer aux pirates. Après quoi, ces derniers ont simplement modifié l’adresse de connexion utilisée pour se connecter à NPM.

Le 9 septembre, Josh Junon a publié un message d’excuses sur Hacker News, dans lequel il admet honteusement : « yep I got pwned ». Le même jour, jFrog indiquait de son côté que la campagne continuait et que de nouveaux paquets contaminés avaient été découverts, dont DuckDB. Toujours le 9 septembre, SlowMist avertissait que d’autres développeurs recevaient le même e-mail, signe que Josh Junon n’était pas un cas isolé.

Tout s’enchaine très vite

Une chaine d’approvisionnement contaminée sur des paquets aussi populaires aurait constitué une catastrophe pour de nombreux produits. Ces attaques sont notamment très efficaces contre des composants impliqués dans le web de manière générale. Or, avec la multiplication des applications web encapsulées, cela pouvait signifier une diffusion à très grande échelle du code vérolé. Pourtant, tout s’est achevé en quelques heures, sans grande casse.

Sur le blog de la Security Alliance, on peut lire dans le billet du 9 septembre une note ironisant sur les 5 cents d’ETH ou encore les 20 dollars d’un memecoin. Dans les heures qui ont suivi la compromission, seuls 588 dollars de transactions auraient été détectés. Ce qui fait dire à l’Alliance que le plus gros impact financier de l’attaque réside finalement dans « les milliers d’heures passées collectivement par les équipes d’ingénierie et de sécurité du monde entier à nettoyer les environnements compromis, et les millions de dollars de contrats de vente qui seront inévitablement signés à la suite de cette nouvelle étude de cas ».

Cité par Brian Krebs, le pentester Philippe Catureli, responsable sécurité chez Seralys, s’en étonne également : « Ce qui est fou, c’est qu’ils ont compromis des milliards de sites Web et d’applications juste pour cibler quelques crypto-monnaies. Il s’agissait d’une attaque de la chaîne d’approvisionnement, et cela aurait facilement pu être quelque chose de bien pire que la récolte de crypto-monnaies ».

Même son de cloche chez Florian Roth, chercheur en sécurité chez Nextron Systems : « Étant donné que la plupart des entreprises exécutent au moins une application React ou Angular, elles ont eu la possibilité d’exécuter du code sur des millions de systèmes dans des milliers d’organisations. Et ils l’ont utilisé pour lacher un voleur de cryptomonnaies obscurci de manière amateur, ont été attrapés par des règles élémentaires de détection, et le problème a été résolu après 2 heures ». Pas mieux du côté du chercheur Kevin Beaumont.

L’authentification des développeurs à nouveau en question

Dans son billet de blog, Aikido relève également le vaste danger évité de peu. De faibles conséquences qui ne semblent dues qu’au manque de compétences des pirates, en dépit de leur réussite sur la chaine d’approvisionnement.

Pour montrer à quel point ce type d’incident peut être grave, la société belge rappelle une autre compromission qui s’est déroulée fin août. Là aussi, un autre développeur NPM avait été visé, permettant la récupération de ses identifiants et l’insertion d’un code malveillant dans nx, une boite à outils pour le développement open source, totalisant six millions de téléchargements par semaine.

Le code malveillant avait servi à analyser l’ordinateur du développeur pour y récupérer des jetons d’authentification, ainsi que des clés SSH et API. Ces informations n’ont cependant pas été transmises aux pirates : elles ont été publiées dans un référentiel public créé pour l’occasion dans le compte GitHub du développeur, afin qu’elles soient visibles de tous et téléchargeables.

À Brian Krebs, Charlie Eriksen, chercheur chez Aikido, affirme que tous les paquets les plus populaires devraient exiger des attestations pour les modifications de code. De manière plus générale, il est d’avis que des plateformes comme GitHub et NPM devraient relever le niveau de sécurité, en s’assurant que les commits (une proposition de modification du code, pour schématiser) sont proposés par des personnes étant bien qui elles prétendent être.

S’il s’en est fallu de peu pour échapper à une catastrophe, les évènements ne semblent pas avoir surpris les chercheurs en sécurité, qui répètent les mêmes éléments depuis des années. Kevin Beaumont s’en moquait justement avec acidité, rappelant – encore une fois – que certaines des briques logicielles les plus utilisées ne sont gérées que par une poignée de personnes. Renvoyant une fois de plus au célèbre dessin de xkcd sur les dépendances.

Rappelons également que l’authentification à facteurs multiples, si elle apporte un gain majeur de protection, n’est pas absolue. En août 2022, Microsoft avait expliqué en détail par exemple comment un acteur malveillant avait mis en place toute une infrastructure pour récupérer des jetons d’authentification, via notamment des serveurs mimant un comportement légitime. Ce type d’attaque passe systématiquement par la compromission d’une personne, le plus souvent par un e-mail soigneusement préparé.

Papi en aura fait de la résistance

Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d’y voir plus clair.

Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.

On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.

De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.

Qu’est-ce qu’un serveur graphique ?

Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.

Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.

Ubuntu 25.10, attendue le mois prochain, devrait être une version plus riche en modifications techniques qu’habituellement. L’équipe de développement va ainsi procéder au remplacement d’initramfs-tools par Dracut pour son démarrage.

Pour l’utilisateur, il n’y aura aucun changement, pas même dans la vitesse de démarrage de la machine. L’arrivée de Dracut représente cependant une évolution technologique intéressante pour Ubuntu (il est déjà utilisé par Fedora).

De quoi parle-t-on ? Actuellement, quand un ordinateur sous Ubuntu démarre, ce n’est pas le système qui se charge en premier. La première étape est un mini-système qui se charge en mémoire vive. Nommé initramfs, il contient le strict nécessaire pour trouver le stockage, déchiffrer les disques si besoin et passer le relai au système de fichiers du « vrai » système. C’est donc un maillon essentiel de la chaine de démarrage.

Si Fedora est passée à Dracut et qu’Ubuntu s’apprête à faire de même, c’est qu’il apporte plus de souplesse dans cette étape. Là où initramfs est basé sur des scripts, Dracut est organisé en modules et propose une approche dynamique via udev, qui gère la détection matérielle dans Ubuntu. Cette organisation modulaire simplifie son développement et sa maintenance.

Dracut est aussi plus moderne, avec une prise en charge de technologies plus récentes, comme NVMe over Fabrics, indique OMGUbuntu. C’est en outre un choix cohérent pour les technologies déjà présentes dans Ubuntu. La distribution utilise par exemple systemd, dont se sert également Dracut, contrairement à initramfs.

Cette décision n’est pas arrivée subitement. Canonical réfléchit à la question depuis un bon moment et a posé la question du remplacement effectif dans une note du 7 février. Les questions de cohérence technique et de cout de maintenance étaient clairement mises en avant.

La bêta d’Ubuntu 25.10 est attendue pour le 18 septembre et sa version finale le 9 octobre.

Ubuntu 25.10, attendue le mois prochain, devrait être une version plus riche en modifications techniques qu’habituellement. L’équipe de développement va ainsi procéder au remplacement d’initramfs-tools par Dracut pour son démarrage.

Pour l’utilisateur, il n’y aura aucun changement, pas même dans la vitesse de démarrage de la machine. L’arrivée de Dracut représente cependant une évolution technologique intéressante pour Ubuntu (il est déjà utilisé par Fedora).

De quoi parle-t-on ? Actuellement, quand un ordinateur sous Ubuntu démarre, ce n’est pas le système qui se charge en premier. La première étape est un mini-système qui se charge en mémoire vive. Nommé initramfs, il contient le strict nécessaire pour trouver le stockage, déchiffrer les disques si besoin et passer le relai au système de fichiers du « vrai » système. C’est donc un maillon essentiel de la chaine de démarrage.

Si Fedora est passée à Dracut et qu’Ubuntu s’apprête à faire de même, c’est qu’il apporte plus de souplesse dans cette étape. Là où initramfs est basé sur des scripts, Dracut est organisé en modules et propose une approche dynamique via udev, qui gère la détection matérielle dans Ubuntu. Cette organisation modulaire simplifie son développement et sa maintenance.

Dracut est aussi plus moderne, avec une prise en charge de technologies plus récentes, comme NVMe over Fabrics, indique OMGUbuntu. C’est en outre un choix cohérent pour les technologies déjà présentes dans Ubuntu. La distribution utilise par exemple systemd, dont se sert également Dracut, contrairement à initramfs.

Cette décision n’est pas arrivée subitement. Canonical réfléchit à la question depuis un bon moment et a posé la question du remplacement effectif dans une note du 7 février. Les questions de cohérence technique et de cout de maintenance étaient clairement mises en avant.

La bêta d’Ubuntu 25.10 est attendue pour le 18 septembre et sa version finale le 9 octobre.