Autoblog de korben.info

Ce site n'est pas le site officiel de korben.info
C'est un blog automatisé qui réplique les articles de korben.info

Kenneth Reitz - Quand le libre te bouffe

Wed, 18 Mar 2026 21:53:44 +0100 - (source)

Kenneth Reitz, si vous ne le connaissez pas, c'est le gars qui se trouve derrière Requests , la librairie HTTP Python la plus téléchargée au monde. Ce projet a généré des milliards de downloads sur PyPI et aujourd'hui, Kenneth a publié un post de blog qui devrait, je pense, être lu par tous ceux qui donnent de leur temps sur Internet.

Le titre qu'il a choisi résume tout, je trouve : "Open Source Gave Me Everything Until I Had Nothing Left to Give." En gros, le libre lui a tout apporté… jusqu'à ce qu'il n'ait plus rien à donner.

Le parcours de Kenneth, c'est celui d'un mec qui a planté ses études (1,14 de moyenne, excusez du peu !), qui ensuite a bossé chez McDo, et qui finalement a trouvé dans le code libre la validation que personne ne lui donnait. Pour lui, chaque étoile GitHub, c'était quelqu'un qui finalement lui disait : "Tu existes et ce que tu fais a de la valeur."

Alors quand Requests a explosé, Kenneth a "fusionné" avec son projet. Le mainteneur et sa lib Python sont en quelque sorte devenus une seule entité.

Et ça c'est pas bon car quand votre identité repose uniquement sur votre projet, chaque critique devient personnelle, chaque bug report vous ronge, et surtout, y'a plus aucune soupape de décompression. C'est ce qu'il appelle dans son post le "design flaw". Et le plus dingue, c'est que cette immense pression qu'il ressentait lui était en grande majorité infligée par lui-même. En fait, personne ne le forçait. Il s'est juste consumé tout seul, pendant que ses collègues et ses amis saluaient sa productivité "impressionnante" !

Kenneth Reitz

L'histoire pourrait s'arrêter là, mais derrière, en coulisse, et sans qu'il le sache, un trouble bipolaire non diagnostiqué le rongeait. Il a subi à différentes reprises des épisodes maniaques, dont un lors d'une conférence en Suède, et un autre qui l'a mis à l'hôpital durant 12 jours. L'intensité de cet homme lui permettait de coder des choses brillantes mais provoquait chez lui des crises psychiatriques de plus en plus nombreuses. Un moteur en surchauffe qui faisait autant de dégâts que de jolies contributions au monde de l'open source.

Vous vous en doutez, j'ai vu un parallèle assez flagrant avec mon activité et ce que je ressens depuis un bon moment. Je n'ai pas ce type de troubles, certes, mais la pression auto-infligée est bien là, et j'avoue que c'est quasi impossible de ne pas succomber à cette fusion avec son "projet"… donc oui, je peux dire que je vois trèèès bien de quoi parle Kenneth.

Et même si, contrairement à lui, j'ai appris à dire non, ce n'est pas facile de ne pas se laisser bouffer par ceux qui pensent que tout leur est dû (parce que oui, y'a malheureusement cette mentalité du"tu donnes, c'est sympa, du coup on va tout te prendre !").

Tout ceci reste une drogue, une vaine recherche de cette foutue validation qu'on n'a jamais réussi à vraiment obtenir plus jeune d'un père ou d'une mère. On doit être des millions comme ça et le gros problème, c'est que toute cette intensité, c'est hyper destructeur et le moindre petit grain de sable peut tout faire dérailler. Et pourtant, même à genoux, on continue quand même… Allez savoir pourquoi.

Et ce que dit aussi Kenneth, et que j'élargirais au-delà de la sphère open source, à tous ceux qui partagent des choses en ligne, que ce soient les blogueurs, les vidéastes, les podcasteurs ou les mainteneurs de code, c'est simple : Séparez votre identité de votre projet. Moi j'y arrive pas encore, ça me semble impossible mais ça a vraiment l'air d'être la seule voie possible. Et surtout, votre sécurité financière ne devrait jamais dépendre de la bienveillance de votre communauté. Parce que la gentillesse et la reconnaissance des gens, c'est cool mais ça ne paie pas le loyer.

À la fin de son texte, Kenneth écrit un truc qui franchement me déchire le cœur.

Il dit : "Je ne sais pas si je le referai."

Ce gars doit tout à l'open source et l'open source lui doit aussi beaucoup, et en arriver à lâcher ça, ça montre quand même la souffrance qu'il éprouve. Force à lui, franchement !

Bref, allez lire ce texte parce que je pense que c'est important ! Et c'est pas juste pour les devs, ou pour tous ceux qui donnent leur vie à Internet en quelque sorte.

Non, c'est aussi pour tous ceux qui consomment tout cela sans y penser.


Linux sur Mac avec Fedora Asahi Remix 43 (mais pas tous les Mac)

Wed, 18 Mar 2026 18:33:33 +0100 - (source)

Linux sur un Mac Apple Silicon en 2026 serait-ce enfin une option viable ?

En effet, Fedora Asahi Remix 43 vient de sortir et la réponse est... ça dépend de votre Mac. Si vous êtes sur M1 ou M2, ça commence à être sérieux. M3 ? Ça boote depuis janvier mais c'est pas encore utilisable au quotidien. M4, on en est loin. Et M5, ils ne connaissent pas encore...

Du coup, pour ceux qui se demandent quel Linux installer sur un Mac à base de puce Apple, c'est clairement le choix le plus abouti du moment. La grosse news de cette version, c'est l'arrivée du support Mac Pro (le gros desktop à plusieurs milliers d'euros, oui oui). Y'a aussi les micros qui fonctionnent enfin sur les MacBook Pro et Max en M2, et le 120Hz qui débarque sur les MacBook Pro 14 et 16 pouces. Côté bureau, c'est KDE Plasma 6.6 par défaut avec GNOME 49 en alternative, et sous le capot, RPM 6.0 et le backend DNF5 pour la gestion des paquets.

Pour l'installer, c'est toujours la même commande magique :

curl https://fedora-asahi-remix.org/install | sh

Ça se lance directement depuis macOS, ça partitionne votre SSD et ça pose le tout en dual boot. Votre système Apple reste donc intact à côté, et si ça ne vous plaît pas, vous pouvez tout virer proprement. Et si vous êtes déjà sur une version précédente (41 ou 42), la mise à jour passe par DNF System Upgrade ou Plasma Discover. Par contre, oubliez GNOME Software pour les montées de version, ça marche pas encore !

Sauf que... y'a un gros "MAIS" !

En effet, tout ça ne fonctionne qu'avec les puces M1 et M2 donc si vous avez un Mac récent en M3, ça bootera oui, mais le GPU tournera en mode software (LLVMpipe), donc ce sera hyper lent. Et en M4... bah c'est carrément pas encore prêt.

Parce que oui, le reverse-engineering des GPU d'Apple, c'est un boulot de titan, car depuis le départ d'Asahi Lina qui bossait sur le premier driver DRM en Rust du noyau Linux, ça avance forcément moins vite côté graphique. D'ailleurs, quand je vous en avais parlé la première fois en 2022 , le Bluetooth et Thunderbolt manquaient déjà à l'appel... et c'est toujours pas complètement réglé ! En février 2025, le fondateur du projet Hector Martin avait aussi jeté l'éponge, et on se demandait si le truc allait survivre . Visiblement, l'équipe restante (dont Neal Gompa et Davide Cavalca) a décidé de pas lâcher l'affaire 💪.

Côté perf GPU, le driver open source Honeykrisp est désormais conforme Vulkan 1.3 et grâce à l'émulation x86 via FEX + DXVK, des jeux AAA comme Cyberpunk 2077 ou The Witcher 3 tournent sur M1/M2. C'est encore en alpha, faut pas s'attendre à du 60 fps et il faut 16 Go de RAM minimum, mais des jeux indés comme Hollow Knight tournent également déjà à pleine vitesse. Tout ça en reverse-engineering sans aucune doc constructeur... c'est quand même beau ! (Et pas merci Apple pour la transparence, hein...).

Y'a aussi une variante Fedora Server pour ceux qui voudraient transformer leur Mac en serveur headless, ce qui est une utilisation un peu dingue d'une machine à ce prix-là, mais bon, chacun son délire ! Et aussi une image minimale pour les bidouilleurs qui veulent tout construire à la main. Voilà.

Voili voilou, si vous avez un M1 ou M2 sous la main, c'est le moment de tester. Et pour le reste, encore un peu de patience.

Source


Pour faire tourner du JavaScript côté serveur, y'a pas que Node.js dans la vie. Y'a maintenant workerd (prononcez "worker-dee"), qui est le runtime open source de Cloudflare, celui-là même qui fait tourner les Workers en prod (le service tourne depuis 2017, le runtime est open source depuis 2022), et que vous pouvez l'installer sur votre Debian, votre Mac ou même votre PC Windows avec un simple npx.

Mais alors pourquoi s'embêter avec un énième runtime JS ?

Hé bien parce que celui-ci n'est pas un runtime généraliste. C'est un vrai serveur HTTP pur et dur, basé sur le moteur V8 de Chrome, conçu pour recevoir des requêtes et y répondre. Pas de filesystem, pas d'accès disque sauvage... ici, votre code vit dans un isolate V8, bien cloisonné, et communique avec l'extérieur uniquement via des bindings explicites qu'on appelle des "capabilities". En gros, votre Worker ne peut accéder qu'aux ressources qu'on lui a branchées dans son fichier de config Cap'n Proto .

Et cela a plein d'avantages ! Par exemple, les attaques SSRF classiques c'est mort ! Et n'oubliez pas que c'est du JavaScript pur, donc y'a pas d'affreux require('fs') ni de child_process qui traîne.

Et le concept qui tue, ce sont les nanoservices. En fait, faut imaginer des microservices, mais qui tournent tous dans le même processus Linux, sur le même thread. Comme ça quand un nanoservice en appelle un autre, y'a zéro latence TCP, c'est un juste appel de fonction local !

Et vous pouvez en faire tourner des centaines sur un seul serveur parce que les API sont implémentées en C++ natif et tous les isolates V8 partagent le même code compilé en mémoire. C'est carrément pas intuitif, mais visiblement, ça tient la route.

Côté rétrocompatibilité, c'est cool puisque chaque Worker déclare une "date de compatibilité" dans son fichier .capnp. Comme ça, vous fixez compatibilityDate = "2024-06-15" et le runtime vous garantit que les API fetch() et WebCrypto se comporteront toujours comme à cette date-là, même si le binaire a été recompilé 200 fois depuis. Des releases sortant tous les jours, cette garantie n'est pas anecdotique !

Cap'n Proto, un format de sérialisation binaire créé par Kenton Varda, le même gars qui est derrière Protocol Buffers chez Google (excusez du peu). C'est un poil déroutant au début si vous êtes habitués au YAML ou au JSON, mais c'est très efficace et hyper rapide. Et pour ceux qui bossent déjà avec l'écosystème Cloudflare parce que vous avez l'Amérique qui coule dans les veines, sachez le runtime s'intègre nickel avec l'outil CLI Wrangler pour le dev local.

Par contre, attention, ce n'est PAS un sandbox sécurisé. Cloudflare le dit cash : si vous faites tourner du code potentiellement malveillant, faudra l'isoler dans une VM KVM ou un conteneur Docker. Hé oui les amis, en prod chez Cloudflare, y'a des couches de sécurité supplémentaires (isolation kernel Linux, patching V8 en urgence, segmentation par profil de risque) que le runtime seul ne fournit pas.

Le problème, c'est surtout Spectre et les bugs du moteur V8... car ça reste du code C++ compilé avec clang derrière. Après, pour du self-hosting de vos propres Workers sur votre VPS Ubuntu, c'est largement suffisant.

Maintenant pour tester concrétement c'est mui rapido.

npx workerd serve config.capnp

Vous écrivez un petit hello.js avec un addEventListener("fetch"), et hop, vous avez un serveur HTTP prêt à répondre sur le port 8080 de votre localhost. Et le truc sympa, c'est qu'on peut aussi l'utiliser comme proxy HTTP programmable !

Comme ça, au lieu de configurer des règles nginx ou Apache absconses, vous écrivez du JavaScript standard avec des Request et Response pour intercepter et router vos requêtes. Franchement, pour du reverse proxy avec de la logique métier, c'est quand même plus lisible que du location ~ ^/api/(.*)$. ^^

D'ailleurs, côté API, tout est basé sur les standards W3C : fetch(), URL, WebCrypto, TextEncoder, les classiques quoi. Donc si vous savez écrire du JS pour Firefox ou Chrome, vous savez écrire pour le moteur des Workers. Pas de modules propriétaires bizarres, contrairement à Node.js et tous ses packages http, net, stream...

Bref, c'est costaud, c'est gratuit, et ça tourne partout, avec un dossier samples/ plein de configs prêtes à l'emploi.

Allez, je vous libère, vous pouvez foncer tester ça !!


Si vous avez un site web et que vos illustrations ressemblent comme sur mon site, à un joyeux bordel de screenshots pixelisés, de photos libres de droits et d'images IA plus ou moins réussies, y'a peut-être un moyen de donner une certaine cohérence visuelle à tout ça. L'outil s'appelle Dither , ça a été créé par Shpigford , et c'est un générateur de tramage vectoriel qui tourne directement dans Chrome, Firefox ou Safari, sans inscription ni installation.

L'interface de Dither avec ses réglages d'algorithme et de palette

Le principe est simple... Vous balancez un fichier JPEG ou PNG et hop, le moteur JavaScript le transforme en utilisant des algorithmes de dithering comme Bayer (en 2x2, 4x4 ou 8x8), du halftone, des lignes, des croix, des points ou encore des écailles.

Neuf algorithmes au total et ce qui est vraiment cool, c'est qu'il y a des palettes prédéfinies dont une palette Game Boy qui donne ce rendu vert olive mythique qu'on avait sur l'écran LCD 160x144 de la jolie brique de Nintendo. Y'a aussi du CGA et du Sepia pour ceux qui veulent varier les ambiances et pour le coup, ça envoie bien du rétro !

Pour les djeuns, sachez que le dithering c'est en fait cette vieille technique qui remonte aux années 70-80 permettant de simuler des dégradés quand on n'a que quelques teintes disponibles. En gros, au lieu d'un dégradé lisse en 16 millions de couleurs RGB, on place des petits points de 2 à 8 couleurs qui, vus de loin, donnent l'illusion d'un mélange. C'est exactement ce qu'on voyait sur les écrans CGA 320x200 des vieux PC IBM XT ou sur la Game Boy sortie en 1989.

L'intérêt d'un outil comme Dither, c'est qu'en plus de jouer avec les 9 algorithmes, vous pouvez régler pas mal de paramètres via l'interface. Par exemple, la taille des cellules en pixels (8px par défaut, mais j'ai trouvé que 12px donne un bon compromis lisibilité/esthétique sur des photos 1024x768), l'angle de rotation du motif à 45 degrés, l'échelle à 1.0, et même choisir entre cercle, carré ou diamant pour la forme du rendu.

Vous pouvez aussi partir d'un gradient linéaire, radial ou conique au lieu d'une image existante... pas mal pour générer des fonds d'écran rétro sur macOS ou Linux !

Et surtout, l'export se fait en SVG ou en PNG. Le SVG c'est super pratique si vous voulez intégrer le résultat dans un site web via une balise <img> sans perte de qualité, vu que c'est du vectoriel.

Par contre, attention, le mode Sepia a tendance à écraser les contrastes sur les photos sombres en dessous de 128 de luminosité moyenne... du coup préférez le mode B/W ou CGA sur ce type d'images.

Sachez aussi que les photos avec beaucoup de détails fins (genre une photo de foule ou un paysage urbain en 4000x3000) perdent carrément en lisibilité avec les petites cellules de 4px ou 8px. Montez la taille à 16px ou 32px dans ce cas, vous verrez, ça change tout.

Bon après, est-ce que je vais mettre toutes les images de mon site en mode pixel art tramé ? Non, clairement pas, car ça deviendrait monotone à force. Mais pour un projet perso, un portfolio, un zine en ligne ou même une série d'articles thématiques, ça peut donner un look uniforme sympa.

Bref, allez jeter un oeil, c'est gratuit et ça tourne dans le navigateur.

Merci à Lorenper pour la découverte !


ClamUI - Enfin un antivirus graphique sous Linux

Wed, 18 Mar 2026 16:47:30 +0100 - (source)

ClamAV, tout le monde connaît. C'est le moteur antivirus open source qui tourne sur à peu près tous les serveurs mail de la planète. Sauf que côté bureau Linux, à part ClamTk qui commence à dater, les options pour le piloter avec une interface graphique sont plutôt limitées.

Heureusement, ClamUI vient corriger le tir avec une vraie application desktop qui se présente comme une interface GNOME native bien léchée pour scanner vos fichiers, gérer la quarantaine et garder un oeil sur la sécurité de votre bécane. Un petit

flatpak install flathub io.github.linx_systems.ClamUI

...et c'est réglé !

Bon, vous allez me dire "Un antivirus sous Linux, pour quoi faire ? Moi j'ai une vraie barbe, je bois de la chouffe cul-sec et suffit de pas installer n'importe quoi, c'est tout !!! Linux ça se mérite les moldus !" tout en embrassant vos biceps ramollis ^^.

Mais vous oubliez que si vous partagez des fichiers avec des machines Windows, si vous gérez un serveur de mails ou un NAS familial, scanner ce qui transite c'est pas du luxe. Et ClamUI rend la chose carrément accessible, là où avant fallait jongler avec des outils en ligne de commande comme ceux qu'on trouve dans les distributions d'analyse de malwares .

Côté fonctionnalités, c'est d'ailleurs plutôt complet ! L'appli détecte automatiquement les clés USB et disques externes quand vous les branchez, et peut les scanner direct sans que vous leviez le petit doigt (un peu comme CIRCLean sur Raspberry Pi , mais sans le matériel dédié). Y'a aussi l'intégration VirusTotal pour les fichiers véritablement louches (il faut juste une clé API gratuite), du coup vous pouvez croiser les résultats avec une soixantaine de moteurs de détection en un clic.

Une chose bien pensée aussi, c'est l'intégration dans les gestionnaires de fichiers comme Nautilus, Dolphin, Nemo... un clic droit sur n'importe quel répertoire et vous lancez un scan. Ça s'installe également dans le system tray avec des notifications en temps réel, genre "scan terminé, zéro menace détectée" ou "attention, fichier suspect déplacé en quarantaine".

Pour les bidouilleurs, ClamUI propose deux backends au choix, c'est-à-dire soit le daemon clamd, plutôt que clamscan en direct, parce que clamd garde les signatures en mémoire et scanne beaucoup plus vite. Mais si vous voulez pas d'un service qui tourne en permanence, clamscan fait le job. Vous pouvez aussi programmer des scans automatiques via systemd ou cron, donc même un vieux serveur Debian peut tourner en pilote automatique.

Y'a aussi une CLI complète derrière l'interface graphique, idéale pour l'intégrer à vos scripts. clamui scan, clamui quarantine, clamui profile, clamui status... tout sort en JSON si vous voulez scripter le truc. Les codes retour sont d'ailleurs très propres : 0 si c'est clean, 1 si y'a des menaces, 2 si erreur. "Èzé" comme dirait Booba ! De quoi intégrer ça dans un pipeline de vérification maison sans se prendre la tête !

Le projet est sous licence MIT, tourne avec Python 3.11+ et les sources sont sur GitHub .

Merci à Lorenper pour la découverte !


Un chercheur indépendant vient de présenter le 5500FP, un processeur qui ne fonctionne pas en binaire mais en ternaire. Là où nos puces actuelles raisonnent en 0 et 1, celui-ci ajoute un troisième état : le -1. Le tout tourne sur un FPGA classique, et c'est le premier matériel ternaire généraliste depuis les années 1960.

Trois états au lieu de deux

Nos processeurs fonctionnent tous en binaire : chaque bit vaut 0 ou 1. Le système ternaire, lui, remplace le bit par un trit, qui peut valoir -1, 0 ou +1. Sur le papier, un trit stocke environ 1,58 fois plus de données qu'un bit. L'idée n'est pas nouvelle : le célèbre informaticien Donald Knuth a décrit le système ternaire comme le plus élégant des systèmes numériques.

Dans les années 1950, une équipe de l'Université de Moscou avait construit le Setun, le premier ordinateur ternaire. Mais la technologie binaire a pris le dessus, et depuis les années 1960, plus personne n'avait fabriqué de matériel ternaire fonctionnel.

Le 5500FP, un processeur RISC à 24 trits

Claudio Lorenzo La Rosa, chercheur indépendant, a conçu le 5500FP : un processeur RISC de 24 trits qui fonctionne à 20 MHz sur un FPGA classique. Il dispose de 120 instructions et gère la synchronisation atomique en natif. La carte de développement est en open hardware.

Comme le Setun avant lui, le 5500FP simule la logique ternaire à partir de composants binaires : chaque trit est représenté par deux portes logiques. Ce n'est donc pas aussi efficace qu'un vrai circuit ternaire, mais ça a un avantage de taille : on peut le construire avec des composants disponibles dans le commerce, et il communique sans problème avec le reste du monde informatique, qui reste 100% binaire.

Pourquoi c'est intéressant ?

Le ternaire équilibré simplifie certaines opérations que le binaire gère mal. Les nombres négatifs, par exemple, se manipulent sans bit de signe dédié : il suffit d'inverser tous les trits. La représentation des chiffres est aussi plus compacte.

Mais bon, le 5500FP reste un prototype de recherche à 20 MHz, on est très loin d'un concurrent pour les puces que l'on trouve dans nos Mac ou nos iPhone. L'objectif de La Rosa est de passer à terme du FPGA au silicium, ce qui permettrait d'atteindre des fréquences bien plus élevées.

C'est le genre de projet qui rappelle que l'informatique aurait pu prendre un chemin totalement différent. Le binaire s'est imposé dans les années 1960 pour des raisons industrielles plus que scientifiques, et depuis, personne n'a vraiment remis en question ce choix.

Source : Zenodo


Les boîtiers KVM IP, c'est le genre de matos qu'on branche dans un rack et qu'on oublie dans un coin pendant des années. Hé bien va falloir vous souvenir de où vous les avez mis les copains parce que des chercheurs d'Eclypsium viennent de retourner de fond en comble 4 modèles populaires... et c'est pas joli joli. A l'intérieur il y on trouvé pas moins de 9 failles, dont une qui score à 9.8 sur 10 en gravité CVSS. Autant dire qu'on n'est plus dans le "petit bug rigolo oh oh" qui fait marrer votre admin sys.

Pour ceux qui débarquent, ces petits appareils dont l'acronyme veut dire "Kernel-based Virtual Machine", permettent de contrôler un serveur à distance via le réseau, clavier, souris et écran compris, comme si vous étiez physiquement devant la machine. Hyper pratique donc pour gérer un homelab ou une salle serveur, et ça coûte entre 50 et 200 euros sur Amazon. Du coup, y'en a partout !!!

Les chercheurs Paul Asadoorian et Reynaldo Vasquez Garcia ont passé au crible le GL-iNet Comet RM-1, le JetKVM, le Sipeed NanoKVM et l'Angeet ES3 et ça fait mal : authentification manquante sur des fonctions critiques, injection de commandes OS, ports UART qui filent un accès root direct, et des firmwares qu'on peut remplacer sans aucune vérification de signature. En gros, c'est la fête du slip côté sécu !

Le truc vraiment relou avec ce type d'appareils, c'est qu'en fait ils opèrent en dessous de votre OS. Pas d'antivirus, pas d'EDR, rien ne les voit. Un attaquant qui compromet votre switch de contrôle distant peut alors injecter des frappes clavier, booter depuis une clé USB (bye bye le chiffrement de disque et le Secure Boot), contourner l'écran de verrouillage, et planquer une backdoor directement dans le firmware du boîtier. Tout ça sans que votre machine ne bronche car un KVM compromis, c'est pas un stupide gadget IoT de plus sur votre réseau... Là je vous parle vraiment d'un accès direct et silencieux à toutes les machines qu'il contrôle.

Et c'est pas juste théorique puisqu'en 2025, des travailleurs nord-coréens infiltrés dans des boîtes américaines utilisaient des PiKVM et TinyPilot pour contrôler à distance les laptops d'entreprise depuis des "laptop farms". Voilà le genre de scénario qu'on rend possible quand le firmware n'a même pas de signature. C'est un peu comme ces caméras IoT bourrées de failles sur lesquelles un chercheur faisait tourner DOOM... sauf qu'ici, l'attaquant prend le contrôle de vos serveurs, pas d'un flux vidéo.

Et histoire de parfaire le tableau, côté correctifs c'est la jungle intégral !! JetKVM a patché en v0.5.4, Sipeed en v2.3.1, GL-iNet promet un fix en v1.8.1 beta et pour l'Angeet ES3, qui cumule les 2 failles les plus sévères (scores 9.8 et 8.8), y'a aucun correctif prévu. Oupsy oups...

Donc si vous avez un de ces boîtiers qui traîne, voilà ce qu'il faut faire. D'abord isolez-le sur un VLAN de management dédié (jamais sur le réseau principal), coupez-lui l'accès Internet, activez le MFA si c'est supporté, et vérifiez que votre appareil n'est pas exposé publiquement via un scan de votre IP. Mettez également le firmware à jour, sauf si c'est un Angeet... là, franchement, faut débrancher.

Bref, si vous avez un de ces machins dans votre rack, traitez-le comme un point d'accès critique... parce que c'en est un !

Source


Telnet en big 2026... bah oui ça existe encore les amis ! Et surtout c’est toujours aussi troué ! J'en veux pour preuve le daemon telnetd de GNU InetUtils qui vient de se prendre une 2ème faille critique en l’espace de deux mois, et celle-là, elle pique de fou !

Il s'agit de la CVE-2026-32746 , elle permet d’obtenir un shell root sur n’importe quel serveur Linux ou BSD exposant le port 23, et l’attaque se fait avant même que le prompt de login n’apparaisse. Pas besoin de mot de passe, pas besoin de compte. Juste une bonne vieille connexion TCP et un paquet SLC malformé et c'est parti mon kiki !

En fait, le bug se planque dans le handler SLC (Set Local Characters) du code source C de telnetd. Ainsi, quand un client ouvre une socket TCP sur le port 23, y’a une phase de négociation d’options avant l’authentification. L’attaquant envoie alors un paquet SLC contenant un nombre anormal d'octets, et ça déclenche un buffer overflow de type out-of-bounds write dans la mémoire du processus. Et boom, exécution de code arbitraire avec les privilèges root ! Et ça, ça donne un score CVSS de 9.8 sur 10 soit quasi la note maximale !

Toutes les versions de GNU InetUtils telnetd jusqu’à la 2.7 sont touchées. Toutes vulnérables, et pour le moment, aucun patch n’est disponible à ce jour. C’est la boîte de cybersécurité israélienne Dream, via son chercheur Adiel Sol, qui a découvert le pot aux roses et publié l’advisory le 11 mars dernier. Le patch officiel du mainteneur GNU est attendu pour le 1er avril (et non, c’est pas un poisson).

Ça craint surtout qu'il y a à peine 2 mois, une autre faille critique dans le même daemon, la CVE-2026-24061 (aussi scorée 9.8), avait déjà été divulguée. Et celle-là, la CISA l’a depuis ajoutée à son catalogue de vulnérabilités activement exploitées dans la nature. Ça me rappelle carrément la faille RCE dans cups-browsed l’an dernier... Ces vieux services réseau, c’est dingue comme ça revient régulièrement.

Donc gaffe à vous parce que si vous avez du telnetd qui traîne quelque part (serveurs Debian, switchs Cisco, automates Siemens, imprimantes HP réseau...), faut agir vite.

Déjà, désactivez le service avec un

systemctl stop telnet.socket && systemctl disable telnet.socket

ou éditez /etc/xinetd.d/telnet si vous êtes sur un vieux système.

Sinon, on bloque le port 23 avec un

iptables -A INPUT -p tcp --dport 23 -j DROP

... plutôt que de laisser ça ouvert aux quatre vents. Isolez aussi l’accès via un VLAN dédié aux seuls réseaux autorisés et faites tourner le daemon sans les privilèges root si votre config le permet. Et en couche supplémentaire, je vous recommande le port knocking qui permet de masquer vos ports aux scans automatiques (ça ne corrige pas la faille, mais ça réduit la surface d’exposition).

Par contre, le problème vous l'aurez compris, c’est que beaucoup de ces équipements ne supportent pas forcément SSH. Donc y’a encore des tonnes et des tonnes de switchs managés et d’automates industriels coincés sur telnet parce que le constructeur n’a jamais jugé bon de supporter autre chose.

Et dans ces cas-là, le seul vrai plan de secours finalement, c’est ce bon vieux firewall et un peu d’isolation réseau. C'est pas l'idéal, mais c’est toujours mieux que rien.

Bref, bloquez le port 23 et passez à SSH. C’est quand même pas compliqué, meuuuuh !!

Source


Google vient de rendre public Sashiko, un outil de revue de code par intelligence artificielle qui analyse automatiquement les correctifs soumis au noyau Linux. Sur un échantillon de 1 000 bugs récents, l'IA en a détecté 53 %, alors que les relecteurs humains les avaient tous ratés sans exception.

Comment fonctionne Sashiko

Sashiko a été développé en interne par l'équipe Linux de Google, sous la direction de Roman Gushchin. Le principe : chaque correctif envoyé sur la liste de diffusion du noyau Linux est automatiquement analysé par une IA qui cherche les erreurs, les incohérences et les bugs potentiels.

Sans surprise, c'est Gemini Pro 3.1 qui fait tourner l'outil, mais il est aussi capable de tourner avec d'autres modèles, comme Claude.

Ce projet s'appuie sur les recherches de Chris Mason, un développeur qui rédige des prompts de revue de code pour l'IA depuis fin 2025. Sashiko va encore plus loin, car il automatise l'intégralité du processus.

D'ailleurs, l'outil est open source et est hébergé sur GitHub. Son transfert vers la Linux Foundation est d'ailleurs en cours, et Google continue à financer l'infrastructure ainsi que les coûts d'usage de l'IA.

100 % des bugs détectés

Le chiffre qui retient l'attention, c'est que 100 % des bugs détectés par Sashiko avaient échappé aux développeurs humains. Sur les 1 000 correctifs récents qui portaient la mention de correction de bug, l'IA a repéré plus de la moitié des problèmes.

Le noyau Linux reçoit des milliers de contributions chaque mois, et les mainteneurs n'ont pas toujours le temps de tout vérifier avec la même rigueur. Sashiko ne remplace pas la relecture humaine, mais il ajoute une couche de vérification qui manquait.

L'interface web est accessible publiquement et couvre l'ensemble des soumissions envoyées à la liste de diffusion du noyau. Tout le monde peut consulter les analyses générées par l'IA.

Le noyau Linux, c'est la base d'Android, de Chrome OS, du cloud de Google, d'Amazon et de Microsoft, et d'à peu près tous les serveurs qui font tourner Internet.

Que Google investisse pour fiabiliser ce code avec de l'IA, c'est plutôt logique. Par contre, on imagine bien que certains développeurs vont tiquer à l'idée qu'une machine relise leur travail et pointe des erreurs qu'ils n'ont pas vues.

La question n'est pas de savoir si l'IA va remplacer les développeurs, mais plutôt combien de temps il faudra avant que ce genre d'outil devienne la norme dans tous les gros projets open source.

Source : Phoronix


Electronic Arts recrute un ingénieur senior pour adapter son système anti-triche Javelin aux processeurs ARM64. La priorité va aux PC Windows sur ARM, mais l'offre d'emploi mentionne aussi un futur support de Linux et de Proton. 

De quoi intéresser les joueurs sur Steam Deck et, pourquoi pas, sur Mac.

Un anti-triche qui arrive sur ARM

EA vient de publier une offre d'emploi pour un poste d'ingénieur senior anti-triche ARM64 au sein de son équipe SPEAR (Secure Product Engineering and Anti-Cheat Response). L'objectif principal : développer un driver natif ARM64 pour EA Javelin, le système anti-triche d'EA qui fonctionne au niveau du noyau du système d'exploitation.

La cible immédiate, ce sont les appareils Windows sur ARM, un segment qui prend de l'ampleur avec l'arrivée de consoles portables basées sur des puces ARM, et les futures puces Nvidia N1 et N1X qui se profilent dans le monde du PC portable.

Ce qui est intéressant, c'est une ligne un peu plus discrète dans l'offre d'emploi : le candidat devra "tracer une voie pour qu'EA Javelin supporte d'autres systèmes d'exploitation et matériels à l'avenir, comme Linux et Proton". C'est la couche de compatibilité de Valve qui permet de faire tourner des jeux Windows sur Linux, et donc sur le Steam Deck.

EA et Linux, une relation compliquée

Il faut quand même rappeler qu'EA a retiré le support Linux et Steam Deck d'Apex Legends fin 2024, en expliquant que la nature ouverte de Linux facilitait la triche. Du coup, des jeux comme Battlefield ou EA Sports FC ne fonctionnent tout simplement pas sur Linux.

Cette offre d'emploi va dans le sens inverse, ce qui est plutôt un bon signal, même si on parle bien d'un objectif à long terme et pas d'un lancement imminent.

EA n'est d'ailleurs pas le seul éditeur à avoir eu un rapport tendu avec Linux. Rockstar a coupé le support Linux de GTA V après avoir mis en place BattlEye, et Roblox a bloqué Wine complètement en 2023 avec son système Hyperion.

Le problème de fond reste le même : les anti-triche au niveau du noyau sont très difficiles à adapter sur Linux, où le système est par nature plus ouvert et plus personnalisable.

Un autre point d’intérêt est pour les joueurs Mac, qui pourraient suivre cette annonce de loin. Si EA finit par supporter Proton, ça pourrait aussi faciliter le fonctionnement de ses jeux via CrossOver ou le Game Porting Toolkit d'Apple, qui reposent sur la même base technique.

Bon maintenant attention, on parle ici d'un système de lutte contre la triche qui s'installe au niveau du noyau de votre système, ce qui pose forcément quelques questions de vie privée et de sécurité.

Source : Gaming on Linux


Powered by VroumVroumBlog 0.1.31 - RSS Feed
Download config articles