Zorin OS 18.1 est officiellement disponible ! Cette mise à jour apporte son lot de nouveautés et le retour d'une version Lite. Voici l'essentiel à savoir.
Linus Torvalds a officialisé Linux 7.0 le 12 avril, et le passage à la version 7 a d'ailleurs été expliquée. Torvalds a dit dans son mail de release qu'il préférait simplement incrémenter le numéro majeur quand les mineures dépassaient la dizaine, histoire de ne pas se retrouver avec un Linux 6.23. Pas de révolution philosophique, juste du bon sens de mainteneur donc.
Derrière cette numérotation, le noyau embarque quand même un paquet de nouveautés qui vont directement impacter les utilisateurs AMD, Intel et ARM64, sans parler d'une petite révolution côté système de fichiers XFS.
La grosse annonce, c'est surtout le nouveau daemon xfs_healer, géré par systemd, qui surveille en temps réel les erreurs de métadonnées et les I/O fautifs. Quand il détecte un problème, il déclenche automatiquement la réparation pendant que la partition reste montée et utilisée, ce qui évite de démonter, de booter sur un live USB ou de croiser les doigts pendant un xfs_repair manuel.
Pour un serveur en prod, c'est énorme. XFS rattrape (et dépasse) ce que Btrfs et ZFS proposaient depuis des années sur ce terrain.
Côté Intel, les TSX (Transactional Synchronization Extensions) sont activées par défaut. Sur un CPU 10e génération ou plus récent, ça donne un léger boost sur les charges multithread. Le support de Nova Lake progresse aussi, et le noyau intègre les premiers bouts de Crescent Island, l'accélérateur IA maison d'Intel qui vise les datacenters.
AMD n'est pas oublié, avec de nouveaux blocs IP graphiques activés pour les futures Radeon. Côté ARM64, le kernel gère désormais les chargements et stockages atomiques de 64 octets, un ajout bas niveau qui profitera aux workloads concurrents. Et pour les amateurs de cartes ARM, le décodage vidéo matériel arrive sur toute une série de single-board computers Rockchip.
Ubuntu 26.04 LTS tournera sur Linux 7.0, donc tous les réglages de performance et de stabilité apportés par ce noyau seront directement exploités dans la prochaine LTS. Du coup, choisir Ubuntu cette année a du sens si vous avez du matos récent.
Dans son message de release, Linus évoque aussi la place grandissante de l'IA dans l'écriture de patches noyau. Il ne tranche pas, il observe. On sent qu'il y réfléchit sans vouloir se mouiller pour l'instant.
Bref, pas de révolution, mais le XFS auto-réparant justifie l'upgrade à lui seul pour qui tient vraiment à ses données.
Des attaquants se sont fait passer pour un responsable connu de la Linux Foundation sur le Slack du TODO Group, un groupe de travail dédié aux bureaux de programmes open source. L'objectif, piéger les développeurs en les amenant à cliquer sur un lien d'apparence officielle, puis à installer un faux certificat racine sur leur machine.
Le lien était hébergé sur Google Sites, ce qui aide à passer les filtres de sécurité et donne un vernis légitime. Les victimes arrivent sur une fausse page d'authentification Google Workspace, qui récupère leur adresse email et un code de vérification, avant de leur demander d'installer un "certificat Google" pour finaliser la connexion.
C'est là que tout bascule. Installer un certificat racine, c'est donner à l'attaquant la possibilité de signer ou d'intercepter n'importe quel trafic TLS sur la machine.
Sur macOS, le faux certificat télécharge et exécute un binaire nommé gapi depuis une IP externe (2.26.97.61), avec toutes les conséquences qu'on imagine. Sur Windows, c'est une boîte de dialogue de confiance navigateur qui pousse l'installation. Dans les deux cas, la machine est compromise.
OpenSSF, Socket et Help Net Security ont documenté la campagne, qui s'inscrit dans une tendance plus large.
Les attaquants visent de plus en plus les workflows développeurs et les relations de confiance interne plutôt que de chercher une faille zero-day dans le code, parce qu'un ingénieur qui fait confiance à un Slack privé reste une cible bien plus rentable que la lecture de 50 000 lignes de C obscures.
La règle de sécurité à retenir est simple. Aucun service légitime, jamais, ne vous demandera d'installer un certificat racine via un lien reçu en chat ou par email.
Si un message Slack vous y pousse, même depuis un compte interne qui semble légitime, c'est un compromis ou une usurpation. Signalez, ne cliquez pas.
Ce qui est relou, c'est que l'attaque marche précisément parce que les devs open source travaillent beaucoup sur Slack, au milieu de messages techniques qu'ils traitent à la chaîne. C'est donc franchement fourbe.
Bref, vous l'avez compris, un certificat racine demandé par chat, c'est toujours non.
Linus Torvalds a officialisé la sortie du noyau Linux 7.0 ! Quelles sont les nouveautés ? S'agit-il d'une version majeure ? Voici l'essentiel à savoir.
La France pourrait s'appuyer sur NixOS et sa configuration Sécurix pour équiper les PC de ses agents et ainsi passer sur Linux. Mais NixOS, c'est quoi ?
Pour s'affranchir de Windows, l'État français mise sur deux projets aux noms dignes d'irréductibles Gaulois : Securix, un Linux basé sur NixOS et Bureautix.
Redox OS vient de publier son dernier rapport d'avancement et il y a du nouveau. En plus des progrès sur les pilotes graphiques et le bureau COSMIC, le projet open source a adopté une politique stricte : toute contribution générée par une intelligence artificielle sera refusée et son auteur banni. Carrément.
Du code IA ? Dehors.
Redox OS ne veut pas de code écrit par ChatGPT, Copilot ou tout autre modèle de langage. La règle est inscrite dans les directives de contribution du projet : toute soumission identifiée comme générée par un LLM (issues, merge requests, descriptions) sera immédiatement fermée. Et quiconque tente de contourner la règle se fait bannir du projet. Le tout est présenté comme non négociable.
Redox OS rejoint d'autres projets open source qui ont pris la même direction ces derniers mois, comme Fedora, Gentoo, le projet Rust lui-même ou LLVM, qui ont tous eu à gérer des vagues de contributions de mauvaise qualité générées par IA.
COSMIC, GPU et nouveau scheduler
En parallèle, le mois de mars a été productif côté technique. La démo libcosmic tourne désormais dans le compositeur COSMIC sur Redox, ce qui veut dire qu'on se rapproche d'un vrai bureau utilisable. Les pilotes graphiques ont aussi avancé : support du mapping mémoire GPU sur le pilote Intel, mise en place de shadow buffers pour améliorer les performances, et du travail sur l'API DRM.
Le noyau a aussi reçu un nouveau planificateur de tâches (Deficit Weighted Round Robin) et une meilleure détection des deadlocks. Côté paquets, CPython, PHP, Nano et Vim ont été mis à jour avec le support Unicode via ncursesw.
Un OS ecrit en Rust, pour quoi faire ?
Pour ceux qui ne connaissent pas, Redox OS est un système d'exploitation open source entièrement écrit en Rust, avec une architecture microkernel. Le projet existe depuis 2015 et cherche à proposer une alternative à Linux et BSD, avec la sécurité mémoire de Rust comme argument principal.
Il est porté par Jeremy Soller, qui travaille aussi chez System76 sur Pop!_OS. Redox n'est pas encore prêt pour un usage quotidien, mais chaque mois le rapproche un peu plus d'un système fonctionnel, et l'arrivée du bureau COSMIC est un gros morceau.
Interdire le code IA dans un projet open source en 2026, c'est quand même une prise de position forte. On peut comprendre la démarche : quand on construit un noyau de système d'exploitation, la qualité du code compte, et les contributions générées par IA ont tendance à créer plus de travail qu'elles n'en économisent pour les mainteneurs.
Mais bon, la politique reconnaît elle-même qu'il est impossible de détecter du code IA non étiqueté, ce qui pose la question de l'efficacité réelle de la mesure. Côté technique, voir COSMIC tourner sur Redox est une bonne nouvelle pour tous ceux qui suivent le projet de près. Après dix ans de développement, l'OS en Rust commence à ressembler à quelque chose.
Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.
Un processeur de 1989
L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.
Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.
La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.
Du ménage dans le code
Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.
Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.
Et le 32 bits, alors ?
Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.
Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.
Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.
Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.
En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !
Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.
La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.
Quatre failles, dont une critique
Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.
La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.
Des fichiers supprimés et des téléchargements détournés
La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.
Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.
Qui doit mettre à jour
Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.
La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.
C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.
Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.
CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.
Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.
Quand l'IA fait le boulot des chercheurs en sécurité
C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des
agents IA
pour analyser le code de CUPS et débusquer les problèmes.
Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.
Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.
Deux failles qui se complètent
La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.
CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.
La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.
Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d'
écraser des fichiers système
en tant que root.
Pas de patch, mais des correctifs dans les tuyaux
Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.
Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.
Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.
C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.
Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.
Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.
Enfin !
Ce module s'appelle
hid-omg-detect
et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.
D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.
Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers
USBGuard
pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !
Mais alors pourquoi lancer ça maintenant ?
Hé bien parce que les outils d'attaque USB sont devenus légion ! Les
câbles O.MG
(créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois,
des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB
... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.
Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme
USBRip
(un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.
On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les
attaques par périphériques USB piégés
. Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !
Guide complet pour apprendre à installer et configurer AdGuard Home sur Linux pour bloquer les pubs sur tous les appareils du réseau (PC, TV, smartphone, etc).
Avec Ubuntu 26.04 LTS, les 6 Go de RAM deviennent la base recommandée pour Ubuntu Desktop. Cette évolution interroge face à la flambé des prix de la mémoire.
Et si je vous disais qu'on pouvait faire tourner Firefox dans un terminal ? Et pas un navigateur en mode texte, hein. Non, le véritable Firefox, avec ses onglets, les images, la totale... Hé oui c'est possible et que ça fonctionne via SSH, donc depuis un serveur distant. Bienvenue dans le futur (ou le passé, j'sais plus trop) !
Term.everything
c'est un compositeur Wayland construit from scratch en Go qui, au lieu de balancer l'image sur votre écran, la convertit en caractères ANSI et l'affiche dans le terminal. Du coup, n'importe quelle app GUI Linux peut tourner là-dedans. Firefox, un gestionnaire de fichiers, un lecteur vidéo... et même Doom (parce que si ça peut pas faire tourner Doom, ça compte pas). Le binaire fait une poignée de Mo, c'est sous licence AGPL-3.0, et y'a zéro dépendance externe.
L'outil propose 2 modes d'affichage. Le mode basique qui convertit les pixels en blocs Unicode, et dont la qualité dépend du nombre de lignes et colonnes de votre terminal. Plus vous zoomez out (Ctrl+- sur Alacritty), plus c'est net... mais plus ça rame. Donc si votre terminal supporte le protocole image, genre Kitty ou iTerm2, l'autre mode, c'est du rendu pleine résolution et là non seulement c'est pas dégeu mais en plus ça marche bien !
Le truc vraiment dingue, c'est surtout le SSH parce que si vous avez un serveur Linux distant, vous vous connectez dessus en SSH, vous lancez term-everything firefox et hop, Firefox s'affiche dans votre terminal local. Pas de X11 forwarding relou à mettre en place ni de VNC / RDP zarbi.
Pour les admins sys qui gèrent des serveurs headless, c'est quand même sympa ! D'ailleurs si vous aimez
les outils SSH bien pensés
, celui-ci aussi va vous plaire.
Par contre, on est encore en bêta et certaines apps vont planter ou refuser de se lancer. C'est normal, c'est un compositeur Wayland complet écrit par un seul gars (chapeau l'artiste !). Ce n'est donc pas le genre de truc qu'on met en prod, mais pour du dépannage sur un serveur Debian distant ou juste pour la beauté du geste, ça envoie du pâté.
Le créateur de term.everything est d'ailleurs le même qui avait codé
Fontemon
, un jeu vidéo caché dans une police de caractères. On est donc clairement dans la catégorie "parce qu'on peut le faire et que c'est marrant".
Bref, si vous voulez épater vos collègues en lançant KDE dans un terminal par-dessus SSH, ou juste jouer à Doom dans tmux,
c'est par là que ça se passe.
Amusez-vous bien et merci à Lorenper pour l'info !