varlog/_cache/similar/bd21f099-9b42-4d55-ad06-7f7cc3188a67.json

[{"uuid":"0e4b486e-1540-4bb4-8b9d-1a2844f3ac1b","slug":"20230725-isolation-sandboxing-avec-flatpak-et-snap","title":"L'isolation (sandboxing) avec Flatpak et Snap","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-07-25 18:07:27","created_at":"2023-07-25 18:07:27","updated_at":"2023-07-25 18:07:27","tags":[],"plain":"Une des caractéristiques attrayantes offertes à la fois par les packages Snap et Flatpak est la capacité de placer les applications en cours d'exécution dans un environnement contrôlé (sandbox). Cela signifie que l'application est limitée dans les types d'actions qu'elle peut effectuer et les informations auxquelles elle peut accéder. Tout ce qui se trouve en dehors de l'environnement contrôlé est inaccessible pour l'application. Les technologies Flatpak et Snap fournissent chacune des méthodes pour limiter les actions de leurs packages. Par exemple, nous pouvons empêcher un package Snap ou Flatpak de reproduire du son, d'accéder à certains fichiers, d'afficher des informations sur le bureau ou de communiquer avec d'autres applications en cours d'exécution sur le bureau. Bien qu'il soit techniquement possible de définir les limites de l'environnement contrôlé pour ces deux types de packages à partir de la ligne de commande, la syntaxe n'est pas particulièrement intuitive et la documentation officielle pour les deux formats de package est moins qu'idéale en termes d'exemples pratiques. C'est pourquoi les utilisateurs de packages Flatpak et Snap utilisent généralement des utilitaires graphiques qui permettent de définir facilement les limites des applications. Pour les utilisateurs de Flatpak, l'environnement contrôlé est généralement géré avec l'application Flatseal, elle-même disponible en tant que Flatpak. Flatseal affiche les packages Flatpak installés sur la gauche de sa fenêtre. Sur la droite, une longue liste de permissions que nous pouvons accorder ou refuser pour l'application sélectionnée. La liste est longue et parfois subtile. Par exemple, nous pourrions désactiver la possibilité pour une application de produire du son et être surpris qu'elle puisse quand même générer du son. Cependant, un examen plus approfondi révélera que l'application peut toujours envoyer des données audio à PulseAudio pour être jouées, nous devons donc désactiver cette option également. En d'autres termes, l'interface de Flatseal est simple, mais les options de sécurité interconnectées peuvent ne pas être immédiatement évidentes. Pour les utilisateurs de Snap, le moyen le plus simple d'ajuster les permissions est généralement l'application Software. Snap s'intègre automatiquement au centre logiciel d'Ubuntu et des distributions apparentées. Lorsque nous installons une application ou visitons sa page d'information dans le centre logiciel, un bouton en haut de la page intitulé \"Permissions\" apparaît. En cliquant sur ce bouton, une fenêtre s'ouvre dans laquelle nous pouvons activer ou désactiver les permissions de l'environnement contrôlé pour l'application sélectionnée. La liste des permissions Snap est plus courte que celle présentée par Flatseal, mais je trouve que les options sont bien libellées et, peut-être, plus claires dans leur signification. Les libellés à côté de chaque bascule sont affichés dans un langage que je considère comme plus clair. Sur Flatseal, par exemple, nous verrons des options comme \"Fallback to X11 windowing system\" ou \"PulseAudio sound server\", tandis que pour Snap, nous verrons des options comme \"Play audio\" et \"Access files in your home folder\". Ce dernier est plus facile à comprendre avec moins de connaissances techniques, tandis que la longue liste d'options de Flathub offre peut-être plus de flexibilité. Les deux formats offrent une isolation (sandboxing) flexible et puissante. Les deux environnements isolés offrent des capacités similaires pour limiter les applications."},{"uuid":"4cf880e6-e4e0-42dd-aae2-675837850b83","slug":"compromission-de-jdownloader-6-7-mai-2026-analyse-indicateurs-et-procedure-de-detection","title":"JDownloader : quand le CMS devient la faille","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.webp","published":true,"published_at":"2026-05-12 17:09","created_at":"2026-05-12 17:10:36","updated_at":"2026-05-12 17:21:01","tags":[],"plain":"À propos de l'incident de sécurité affectant le site officiel jdownloader.org les 6 et 7 mai 2026.\r\n\r\nJDownloader expliqué simplement\r\n\r\nJDownloader est un gestionnaire de téléchargements écrit en Java, distribué gratuitement par l'éditeur allemand AppWork GmbH depuis plus de quinze ans. Il sert essentiellement à automatiser la récupération de fichiers depuis des hébergeurs (Mega, Uptobox, Rapidgator…), des plateformes vidéo et des services de liens premium. Côté utilisateur, c'est l'outil qu'on lance pour récupérer une série de fichiers en une opération, plutôt que cliquer sur cent liens un par un. L'application est multiplateforme — Windows, Linux, macOS — et tourne sur quelques millions de postes dans le monde.\r\n\r\nLe projet est distribué de plusieurs façons : un JAR principal (le binaire Java pur), des installateurs natifs par OS depuis le site officiel, et des paquets passant par des canaux distribués comme Flatpak, Snap ou Winget. C'est cette diversité de canaux qui va jouer un rôle central dans ce qui suit.\r\n\r\nL'incident : ce qui s'est passé\r\n\r\nEntre le 6 mai 2026 à 00 h 01 UTC et le 7 mai 2026 à 17 h 06 UTC, le site officiel  a distribué des installateurs piégés à la place des binaires légitimes. La fenêtre n'a duré qu'environ 48 heures, et seuls deux liens ont été affectés. Mais pendant cette fenêtre, tout utilisateur qui passait par le bon parcours téléchargeait un cheval de Troie au lieu d'un gestionnaire de téléchargements.\r\n\r\nLe scénario reconstitué par l'équipe d'AppWork et les chercheurs en sécurité (BleepingComputer, Thomas Klemenc, équipe Rescana) se déroule en quatre temps.\r\n\r\n1. Compromission du CMS du site. Les attaquants ont exploité une vulnérabilité non corrigée dans le système de gestion de contenu de , qui permettait de modifier les listes de contrôle d'accès et le contenu publié sans authentification. Point crucial : ils n'ont pas eu accès au serveur sous-jacent, ni au système de fichiers, ni à l'infrastructure de build. Juste au contenu web — et ça a suffi.\r\n\r\n2. Réécriture de deux liens. Plutôt que de tenter de modifier les binaires originaux (qui étaient hors de leur portée), les attaquants ont fait beaucoup plus simple : ils ont changé l'URL cible de deux liens publics sur la page de téléchargement. Le lien « Download Alternative Installer » pour Windows et le script shell pour Linux pointaient désormais vers des fichiers malveillants hébergés sur une infrastructure tierce. Le HTML autour, lui, restait identique. Visuellement, rien ne distinguait la page propre de la page piégée.\r\n\r\n3. Charges utiles différenciées par plateforme. Sur Windows, l'installateur piégé agit comme un loader qui déploie un RAT (Remote Access Trojan) écrit en Python, fortement obfusqué, communiquant avec deux serveurs de commande et contrôle ( et ). Le RAT est modulaire : il reçoit du code Python depuis le C2 et l'exécute, ce qui donne aux attaquants une porte ouverte indéfiniment extensible. Sur Linux, le script shell modifié télécharge une archive depuis , déguisée en fichier SVG, dont il extrait deux binaires ELF —  et . Le second est installé en SUID-root dans , le premier est copié dans , et la persistance est assurée par un script déposé dans . Le malware se lance ensuite déguisé en , un nom de processus qui existe légitimement sur la plupart des distributions.\r\n\r\n4. Détection par la communauté. L'alerte n'est pas venue d'un système de surveillance, mais d'un utilisateur Reddit (PrinceOfNightSky) qui a remarqué que Microsoft Defender bloquait son installateur fraîchement téléchargé. La signature numérique indiquait « Zipline LLC » au lieu de « AppWork GmbH ». L'équipe AppWork a confirmé, mis le site hors ligne pour investigation dans les heures qui ont suivi, puis publié un rapport d'incident détaillé. Le site est revenu en ligne dans la nuit du 8 au 9 mai avec des liens vérifiés.\r\n\r\nPourquoi c'est systémique\r\n\r\nÀ première vue, c'est un incident isolé : une faille CMS, une équipe qui patche, le service revient. Vu de loin, ça ressemble à un mauvais quart d'heure. Mais en prenant un peu de recul, le schéma est troublant.\r\n\r\nCPUID, début avril 2026. Le site officiel de l'éditeur de CPU-Z est compromis, des installateurs piégés sont distribués pendant plusieurs jours.\r\n\r\nDAEMON Tools, début mai 2026. Même schéma : compromission du site officiel, substitution d'installateurs, plusieurs versions infectées (12.5.0.2421 à 12.5.0.2434) distribuées avant détection.\r\n\r\nJDownloader, 6–7 mai 2026. Toujours le même schéma.\r\n\r\nTrois compromissions d'éditeurs logiciels en cinq semaines, exactement sur le même schéma : pas d'intrusion dans l'infrastructure de build, pas de modification du code source, pas de vol de certificat de signature de l'éditeur. À chaque fois, le maillon faible est le CMS qui sert la page de téléchargement. Ce qu'on attaque, ce n'est pas le logiciel ; c'est le panneau publicitaire qui pointe vers le logiciel.\r\n\r\nCette mécanique est intéressante parce qu'elle déjoue à peu près toutes les défenses « modernes » de la chaîne d'approvisionnement.\r\n\r\nLa signature de code ne protège pas. Le binaire légitime de JDownloader est toujours signé proprement par AppWork GmbH. Mais le binaire malveillant servi à sa place est signé, lui aussi — par un autre éditeur (Zipline LLC, The Water Team), avec des certificats vraisemblablement volés ou achetés au marché noir. La signature certifie que le fichier vient bien de celui qui l'a signé ; elle ne certifie pas que c'est le bon fichier.\r\n\r\nLe HTTPS ne protège pas. La page de téléchargement est servie en HTTPS valide, depuis le bon domaine, avec le bon certificat. Le navigateur n'a aucune raison de tiquer.\r\n\r\nLes mises à jour in-app sont, elles, protégées. AppWork le souligne : chaque mise à jour livrée par le mécanisme intégré de JDownloader est signée RSA et vérifiée cryptographiquement, indépendamment du site web. Ce canal n'a pas été touché. C'est tout le paradoxe : les utilisateurs qui mettaient à jour JDownloader depuis l'application elle-même n'ont rien risqué ; ceux qui sont allés sur le site officiel pour le télécharger « proprement » sont les seuls exposés.\r\n\r\nLes paquets distribués sont protégés. Flatpak, Snap, Winget, le JAR principal — tout ce qui passe par une chaîne d'approvisionnement où l'intégrité est vérifiée par checksum hors site est resté propre. AppWork le résume sans détour : « Winget/Flatpak/Snap infra is outside of our reach — files downloaded by those are hosted on other infra and secured by sha256 checksums that are unchanged. »\r\n\r\nAutrement dit, plus le canal est court et naïf, plus il est vulnérable. Le téléchargement direct depuis un site web est le canal le plus naïf qui soit : on fait confiance au CMS, point. Tout l'effort de sécurisation de l'écosystème logiciel — signatures, builds reproductibles, SBOMs, attestations de provenance — porte sur la chaîne de production et la chaîne de distribution centralisée. Le maillon « page HTML qui dit clique ici », lui, est resté tel qu'il était en 2005.\r\n\r\nComment vérifier si on est touché\r\n\r\nLa fenêtre est étroite, donc le filtrage est simple. Trois questions, dans l'ordre :\r\n\r\n1. L'installateur a-t-il été récupéré entre le 6 mai 2026 (00 h 01 UTC) et le 7 mai 2026 (17 h 06 UTC) ?\r\n2. S'agit-il du lien « Download Alternative Installer » Windows ou du script shell Linux depuis  ?\r\n3. Le fichier a-t-il été exécuté ?\r\n\r\nTrois oui → traiter la machine comme compromise. N'importe quel non dans la liste → aucun risque lié à cet incident. Une installation pré-existante mise à jour automatiquement, un paquet Flatpak/Snap/Winget, le JAR, la version macOS : rien à craindre.\r\n\r\nSous Windows\r\n\r\nLe contrôle de référence, c'est la signature numérique. Clic droit sur l'installateur → Propriétés → onglet Signatures numériques. La valeur attendue est . Toute autre signature (notamment Zipline LLC ou The Water Team), ou l'absence de signature, désigne un fichier malveillant.\r\n\r\nEn PowerShell :\r\n\r\n\r\n\r\nSi  n'est pas  ou si le certificat ne contient pas , ne pas exécuter.\r\n\r\nSous Linux\r\n\r\nTrois artefacts sont à chercher en post-exécution :\r\n\r\n\r\n\r\nL'apparition de l'un de ces trois éléments suffit à confirmer l'infection. Pour aller plus loin, un coup d'œil au trafic sortant vers les trois domaines C2 (, , ) dans les logs DNS ou via  permet de confirmer l'activité du malware.\r\n\r\nSi le script installateur traîne encore quelque part, sa signature est sans ambiguïté : taille de 7 934 496 octets, SHA-256 commençant par .\r\n\r\nEn cas de compromission confirmée\r\n\r\nLa position officielle d'AppWork est sans nuance : réinstallation complète du système. Un RAT modulaire avec persistance SUID-root et exécution arbitraire de code Python depuis un C2 n'est pas quelque chose qu'on retire avec un antivirus. Il faut considérer que tout secret qui a transité sur la machine est compromis — mots de passe saisis au clavier, clés SSH, jetons API, cookies de session, configurations cloud — et les faire tous tourner après réinstallation, depuis une autre machine saine.\r\n\r\nCe que ça change pour qui s'auto-héberge\r\n\r\nL'incident JDownloader est un exemple éclairant pour qui exploite ses propres services exposés sur Internet — un Forgejo, un reverse proxy, un site personnel. La leçon n'est pas vraiment côté utilisateur (la procédure de détection plus haut suffit), elle est côté opérateur.\r\n\r\nLe CMS de JDownloader n'a probablement pas été ciblé pour ses qualités intrinsèques. C'est un dommage collatéral d'un schéma plus large : tout site qui distribue un binaire avec un nombre significatif d'utilisateurs devient une cible rentable, et le CMS public est souvent la pièce la moins surveillée du dispositif. On sécurise le serveur Git, le pipeline de build, la signature des paquets — et on laisse tourner un CMS qui n'a pas été patché depuis huit mois parce qu'il « ne sert qu'à afficher la page d'accueil ».\r\n\r\nQuelques principes opérationnels qui en découlent.\r\n\r\nSéparer le canal de publication du canal de vérification. AppWork a eu raison sur un point essentiel : leurs mises à jour in-app passent par une infrastructure indépendante du site web, avec signature RSA vérifiée côté client. Quand on auto-héberge, ça se traduit par : ne jamais utiliser le même serveur pour distribuer un binaire et publier son empreinte. Le checksum doit vivre ailleurs — dans un dépôt Git séparé, sur un domaine différent, idéalement sur une infrastructure qu'on n'administre pas soi-même.\r\n\r\nSurveiller la dérive du contenu publié. Une simple vérification quotidienne du hash des pages publiques (un cron qui calcule le SHA-256 des URL critiques et alerte en cas de changement non planifié) aurait détecté la compromission de JDownloader en moins d'une heure. C'est le genre de surveillance qu'aucune solution commerciale ne propose nativement, et qui s'écrit en quinze lignes de bash.\r\n\r\nPatcher le CMS avec la même rigueur que l'OS. L'automatisation des mises à jour applicatives reste sous-investie, surtout pour les outils « périphériques » (CMS, wiki, formulaire de contact). Une mise à jour automatique de niveau correctif n'est pas plus risquée qu'une mise à jour du noyau, et elle évite ce type de scénario.\r\n\r\nAuditer les ACL régulièrement. La faille exploitée ici permettait de modifier les ACL sans authentification. C'est l'équivalent CMS d'un répertoire  dans un coin du système. Un audit périodique des permissions sur les pages publiques fait partie du minimum syndical pour un service exposé.\r\n\r\nEn résumé\r\n\r\nJDownloader n'a pas été cassé. Son code source est intact, son infrastructure de build est intacte, ses paquets officiels distribués via Flatpak ou Snap sont intacts, ses mises à jour internes sont intactes. Ce qui a été cassé, c'est le panneau qui dit où aller chercher le binaire.\r\n\r\nC'est une mécanique élégante du point de vue de l'attaquant, et inquiétante du point de vue de l'opérateur. Elle illustre quelque chose que l'incident NPM avait déjà mis en lumière dans un autre registre : la chaîne d'approvisionnement logicielle n'est pas une chaîne, c'est un réseau, et les points faibles ne sont jamais là où on les attend. On peut investir massivement dans la sécurité du code, du build et de la signature ; si la page web qui sert le lien reste un Wordpress non patché derrière un nom de domaine prestigieux, tout cet investissement passe à côté.\r\n\r\nLe rôle de l'opérateur en 2026, ce n'est plus de protéger le code. C'est de protéger chaque maillon qui sert à dire au monde où trouver le code — et de partir du principe que ce maillon-là sera le prochain à céder.\r\n\r\nLiens & sources\r\n\r\nJDownloader site hacked to replace installers with Python RAT malware | BleepingComputer\r\n\r\nRapport d'incident officiel | jdownloader.org\r\n\r\nJDownloader Website Supply Chain Attack | Rescana\r\n\r\nLe site officiel de JDownloader compromis | IT-Connect"},{"uuid":"3e7ef528-6bd0-4fd1-83cb-a0d03ba35949","slug":"npm-le-ver-dans-le-fruit-comprendre-la-faille-systemique-et-repenser-les-pratiques-devops","title":"NPM, le ver dans le fruit : comprendre la faille systémique et repenser les pratiques DevOps","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 13:08","created_at":"2026-05-12 13:08:44","updated_at":"2026-05-12 13:12:42","tags":[],"plain":"À propos de l'article du MagIT « NPM : une nouvelle campagne malveillante souligne une vulnérabilité systémique ».\r\n\r\nNPM expliqué simplement\r\n\r\nQuand on développe une application web moderne en JavaScript ou TypeScript, on ne réécrit jamais tout depuis zéro. On assemble des briques logicielles déjà écrites par d'autres : un module pour parser des dates, un autre pour valider des emails, un troisième pour discuter avec une base de données. Ces briques s'appellent des paquets, et la place de marché centrale qui les distribue s'appelle npm (Node Package Manager).\r\n\r\nConcrètement, dans un projet, on déclare la liste des paquets nécessaires dans un fichier . On lance la commande , et l'outil télécharge automatiquement les paquets demandés… ainsi que tous les paquets dont ces paquets ont eux-mêmes besoin. Un projet « simple » se retrouve souvent à dépendre de plusieurs centaines, voire plusieurs milliers, de paquets en cascade. C'est ce qu'on appelle l'arbre des dépendances.\r\n\r\nLe registre npm héberge aujourd'hui plus de 2,5 millions de paquets. C'est à la fois sa force — un écosystème colossal, une productivité décuplée — et sa faiblesse : la confiance accordée à chaque maillon de la chaîne est implicite, et chaque maillon devient une porte d'entrée potentielle.\r\n\r\nLa faille : ce qui s'est passé\r\n\r\nL'épisode décrit par LeMagIT n'est pas un bug logiciel classique. C'est ce qu'on appelle une attaque sur la chaîne d'approvisionnement logicielle (supply chain attack) : au lieu d'attaquer directement la cible finale, l'attaquant compromet un fournisseur en amont, et laisse la mise à jour légitime faire son travail de propagation.\r\n\r\nLe scénario reconstitué se déroule en plusieurs temps.\r\n\r\n1. Compromission d'un paquet de confiance. Les attaquants sont parvenus à pousser du code malveillant dans des paquets npm largement utilisés, notamment via le détournement du pipeline d'intégration continue de projets connus comme  et l'écosystème Checkmarx. L'astuce n'est pas de publier un faux paquet : c'est de modifier un vrai paquet en exploitant les GitHub Actions — les robots qui construisent et publient automatiquement les nouvelles versions.\r\n\r\n2. Vol de secrets à l'installation. Une fois installé sur la machine d'un développeur ou dans un environnement de build, le code malveillant scanne l'environnement à la recherche de variables sensibles : , , , . Tout ce qui traîne dans les variables d'environnement, les fichiers , les configurations cloud.\r\n\r\n3. Auto-propagation. C'est là que l'attaque devient virale. Avec les jetons npm volés, le maliciel se reconnecte au registre npm, récupère la liste des paquets publiés par la victime, et publie automatiquement des versions piégées de ces paquets. Chaque développeur compromis devient un super-propagateur. Socket a identifié une quarantaine de paquets infectés en cascade lors d'une seule vague.\r\n\r\n4. Persistance. Sur les postes touchés, le malware installe un script  pour survivre aux redémarrages, et, si nécessaire, exfiltre les données volées dans un dépôt GitHub public créé pour l'occasion.\r\n\r\nLe résultat : un binaire signé, publié sous un nom officiel, à jour, qui passe tous les contrôles de surface — et qui contamine simultanément le poste du développeur et les serveurs de production.\r\n\r\nPourquoi c'est « systémique »\r\n\r\nLe terme employé par LeMagIT est juste. Ce n'est pas un bug isolé, c'est une propriété structurelle de l'écosystème.\r\n\r\nLa confiance est transitive. On fait confiance à , qui fait confiance à , qui fait confiance à , etc. Compromettre un nœud profond et populaire suffit à toucher des millions de projets.\r\n\r\nLa publication est ouverte. N'importe qui peut publier un paquet. Les contrôles existent (provenance, 2FA pour les mainteneurs populaires) mais restent surtout a posteriori.\r\n\r\nLes scripts d'installation s'exécutent automatiquement. Un paquet npm peut déclarer un  qui lance du code arbitraire au moment de . C'est pratique, mais c'est aussi un cheval de Troie idéal.\r\n\r\nLes jetons d'API sont partout. Le poste du développeur, les runners CI/CD, les serveurs : tous manipulent des secrets en clair dans des variables d'environnement. Un malware qui s'exécute dans le build n'a même pas besoin d'escalader ses privilèges.\r\n\r\nLes versions sont mutables sur fenêtre courte. Un paquet peut être republié dans les 72 heures suivant sa publication, et un  peut retirer une version d'un jour à l'autre.\r\n\r\nAucun de ces points n'est un défaut technique réparable par un patch. Ce sont des choix d'architecture, vieux de plus de dix ans, qui ont accompagné l'explosion de l'écosystème.\r\n\r\nY a-t-il des alternatives ?\r\n\r\nLa question est légitime, mais la réponse honnête est : pas vraiment, et pour de bonnes raisons.\r\n\r\nLes gestionnaires de paquets alternatifs\r\n\r\n,  et  sont des gestionnaires différents, mais ils tirent leurs paquets du même registre npm. Migrer de  à  ne change rien à la surface d'attaque : ce sont les mêmes paquets, le même registre, les mêmes mainteneurs.\r\n\r\nCela dit, certains apportent des garde-fous utiles :\r\na introduit l'option , qui refuse d'installer un paquet publié il y a moins de N jours. Une vague d'attaque dure typiquement quelques heures avant détection : attendre 72 heures avant d'installer une nouvelle version élimine la fenêtre dangereuse.\r\nimpose un consentement explicite pour les scripts , là où npm les exécute par défaut.\r\net  proposent des lockfiles stricts () qui garantissent que ce qui est installé en CI correspond exactement à ce qui a été testé.\r\n\r\nLes registres alternatifs\r\n\r\nJSR (JavaScript Registry), lancé par les créateurs de Deno, est le seul vrai nouveau registre crédible. Il a été conçu en tirant les leçons des problèmes de npm : TypeScript natif, modules ECMAScript par défaut, pas de scripts d'install, scoring qualité automatique, compatible avec tous les runtimes (Node, Deno, Bun). Mais JSR est complémentaire, pas un remplaçant : il héberge des milliers de paquets, pas des millions. Pour la majorité des dépendances, on continuera de passer par npm.\r\n\r\nLes registres privés — Verdaccio, GitHub Packages, JFrog Artifactory, Sonatype Nexus — ne remplacent pas npm non plus. Ils servent de proxy filtrant : on continue de récupérer les paquets publics, mais à travers un cache d'entreprise où l'on peut bloquer une version, exiger une signature, refuser un mainteneur, ou interdire les paquets publiés depuis moins de X jours. C'est probablement le meilleur compromis disponible aujourd'hui pour une organisation.\r\n\r\nLe verdict\r\n\r\nAbandonner npm en 2026 reviendrait à abandonner JavaScript. La valeur de l'écosystème (2,5 millions de paquets) est trop importante pour qu'on en sorte. Le problème ne se résoudra pas par un changement d'outil ; il se résoudra par un changement de pratiques.\r\n\r\nChanger les pratiques : ce qui doit devenir réflexe\r\n\r\nL'enseignement de cette campagne, et des précédentes (Shai-Hulud, TeamPCP, l'attaque Trivy/KICS), tient en une phrase : la confiance par défaut est morte. Il faut traiter chaque dépendance comme du code hostile par défaut, et le pipeline CI/CD comme une zone de production.\r\n\r\nAu niveau du poste de développement\r\nActiver l'option  (ou équivalent) pour différer l'installation des paquets fraîchement publiés.\r\nDésactiver les scripts  par défaut, et n'autoriser que ceux explicitement validés.\r\nNe jamais stocker de jetons en clair dans  ou les variables d'environnement persistantes. Préférer un gestionnaire de secrets (1Password CLI, , ).\r\nUtiliser des comptes npm séparés pour la publication, avec 2FA matérielle obligatoire.\r\n\r\nAu niveau du dépôt\r\nVerrouiller systématiquement les dépendances (, , ) et installer en mode strict (, ).\r\nMettre en place un audit automatique des dépendances à chaque PR (Socket, Snyk, GitHub Dependabot, ).\r\nPublier ses propres paquets avec provenance npm (signature liée au pipeline GitHub Actions), pour que les consommateurs puissent vérifier l'origine.\r\nTenir à jour un SBOM (Software Bill of Materials) pour savoir exactement ce qui tourne en production.\r\n\r\nAu niveau du CI/CD\r\n\r\nC'est probablement le chantier le plus important.\r\nCloisonner les jetons. Un jeton de publication npm ne doit jamais coexister avec un jeton AWS dans la même étape de pipeline. Un secret par étape, durée de vie minimale, scope minimal.\r\nPréférer les jetons à courte durée de vie (OIDC entre GitHub Actions et le cloud) plutôt que des clés statiques.\r\nAuditer les GitHub Actions tierces. Une action  est l'équivalent d'un . Épingler par hash SHA (), pas par tag mutable.\r\nRestreindre les permissions du  au strict minimum ( par défaut,  ponctuel et justifié).\r\nSurveiller le comportement réseau des runners : un build qui contacte un domaine inconnu doit lever une alerte.\r\n\r\nAu niveau de l'organisation\r\nMettre en place un registre proxy (Verdaccio, Nexus, Artifactory) avec liste blanche/noire de paquets, et l'imposer comme unique source pour tous les projets.\r\nDéfinir une politique de dependency governance : qui peut introduire une nouvelle dépendance, sous quelles conditions, avec quel niveau d'audit.\r\nPrévoir un playbook de révocation : que faire dans l'heure qui suit la détection d'un paquet compromis (rotation de tous les jetons npm/GitHub/cloud, audit des artefacts publiés, communication).\r\n\r\nEn résumé\r\n\r\nNPM n'est pas cassé, il est tel qu'il a été conçu : ouvert, automatique, transitif. Ce qui a changé, c'est la valeur que les attaquants peuvent en extraire — secrets cloud, jetons CI/CD, accès aux pipelines — et la sophistication des campagnes, qui exploitent désormais l'auto-propagation pour atteindre une échelle virale.\r\n\r\nAucune alternative ne supprime le problème, parce que le problème n'est pas npm : c'est l'idée qu'on puisse exécuter en production du code écrit par des inconnus sans jamais le regarder. Le rôle du DevOps en 2026, c'est de bâtir l'infrastructure qui rend cette inspection systématique, économique et inévitable — registres proxy, lockfiles stricts, jetons éphémères, audits continus, isolation des étapes de build.\r\n\r\nOn ne fera pas confiance à moins de gens. On exigera juste que chaque maillon prouve, à chaque exécution, qu'il est bien celui qu'il prétend être."},{"uuid":"c8fa250e-d8b5-453a-a06a-799d53c3b6d1","slug":"la-smart-brick-de-lego-quand-la-brique-devient-intelligente","title":"LEGO : La brique qui répond","category":"loisirs","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-01-13 20:26","created_at":"2026-01-13 20:26:53","updated_at":"2026-05-11 22:45:23","tags":[],"plain":"La brique qui répond\r\n\r\nÀ première vue c'est une brique LEGO comme une autre. Un parallélépipède de plastique gris, le format classique, deux par quatre tenons sur le dessus. On pourrait la prendre, l'emboîter dans un mur, et ne rien remarquer. Sauf que celle-là parle. Elle fait du bruit, elle clignote, elle sait si vous la secouez ou si vous la posez à plat. À l'intérieur, LEGO a réussi à caser un accéléromètre, un capteur de lumière, un capteur de couleur, un haut-parleur miniature et une puce sur mesure plus petite qu'un seul tenon. C'est la LEGO Smart Brick, et elle est arrivée en boutique le 1ᵉʳ mars 2026.\r\n\r\nIl faut tout de suite tordre le cou à un malentendu. La Smart Brick, ce n'est pas un Mindstorms. Ce n'est pas du LEGO éducatif, ce n'est pas une plateforme pour apprendre à coder, et on ne programme rien du tout avec. C'est un objet beaucoup plus simple dans son intention : faire en sorte qu'un set LEGO réagisse quand on joue avec. Vous prenez le X-Wing de Luke Skywalker, vous le faites basculer pour décoller, le brique embarquée détecte le mouvement et joue le bruit du moteur. Vous posez la minifigurine de Dark Vador à côté, la brique la reconnaît grâce à un Smart Tag (une petite tuile codée), et elle déclenche la respiration emblématique du Seigneur Sith. C'est tout. Mais c'est déjà beaucoup.\r\n\r\nLEGO appelle cet écosystème Smart Play. Il repose sur trois éléments. La Smart Brick elle-même, qui est le cerveau et le haut-parleur. Les Smart Tags, des tuiles plates qu'on accroche aux constructions et qui disent à la brique ce qu'elle doit faire à cet endroit (« ici tu joues un bruit de tir laser », « ici tu fais le bruit du réacteur »). Et les Smart Minifigures, des figurines avec un identifiant intégré, que la brique détecte quand on les approche. Le tout communique en local, sans appli obligatoire, sans écran, via un système maison que LEGO a baptisé BrickNet. C'est important : le pari est explicitement de faire de la techno invisible, pas de coller un smartphone entre l'enfant et le jouet.\r\n\r\nCôté pratique, la brique se recharge sans fil. Elle tient environ deux heures et demie en jeu actif, se met en veille au bout de trois minutes d'inactivité et se réveille quand on la secoue. Au-delà d'une dizaine d'heures de veille, il faut la remettre sur son chargeur. Une application gratuite, LEGO SMART Assist, sert à régler le volume, donner un nom à ses briques, gérer plusieurs appareils, et surtout mettre à jour le firmware — parce que oui, une brique LEGO peut maintenant recevoir des mises à jour logicielles. On y est.\r\n\r\nPour le lancement, LEGO a choisi Star Wars, et l'offre est un peu plus subtile qu'il n'y paraît. Huit sets sortent le 1ᵉʳ mars, mais seulement trois contiennent réellement une Smart Brick. Ce sont les coffrets dits All-In-One, qui embarquent la brique, son chargeur, des tags et des figurines intelligentes :\r\n75421 — Chasseur TIE de Dark Vador : 69,99 €, le ticket d'entrée.\r\n75423 — Le X-Wing rouge de Luke Skywalker : 89,99 €.\r\n75427 — Duel dans la salle du trône & A-Wing : 159,99 €, le plus gros, avec deux Smart Bricks.\r\n\r\nLes cinq autres sets — Millennium Falcon, Mos Eisley Cantina, AT-ST Endor, hutte de Yoda, Landspeeder de Luke — sont étiquetés Smart Play mais ne contiennent pas de brique. Ils embarquent juste des tags et des figurines compatibles. Pour qu'ils s'animent, il faut posséder une brique achetée dans l'un des trois coffrets All-In-One, et la déplacer d'un set à l'autre. C'est un choix commercial qu'on peut critiquer : un parent ou un grand-parent qui voit Smart Play sur la boîte de la Mos Eisley Cantina à 79,99 € a de quoi être surpris en rentrant à la maison.\r\n\r\nGéographiquement, le lancement est restreint. Six pays seulement à l'ouverture : États-Unis, Royaume-Uni, France, Allemagne, Pologne, Australie. Le reste du monde attendra.\r\n\r\nPourquoi est-ce intéressant au-delà du cas Star Wars ? Parce que LEGO ne fait pas ça pour vendre trois sets. La marque parle de plus de vingt brevets déposés sur la techno, et de la « plus grande évolution du système LEGO depuis l'introduction de la minifigurine en 1978 ». Le ton est ambitieux, et il y a déjà des rumeurs de déclinaisons sur les gammes Pokémon et Animal Crossing. Si le pari réussit, on parle d'une plateforme qui peut s'étendre à toute la production LEGO sur dix ou vingt ans. Si elle échoue, ce sera la deuxième tentative ratée après les Mindstorms et la gamme Boost, dans la longue liste des essais LEGO pour marier l'électronique au plastique.\r\n\r\nLe point qui me semble vraiment réussi, c'est la philosophie sans écran. Là où la plupart des jouets connectés exigent une tablette pour fonctionner, où l'enfant finit en pratique à regarder un iPad plutôt qu'à jouer avec l'objet physique, LEGO a fait le choix inverse : l'application existe mais elle est facultative, toute l'interaction se passe entre les mains et les briques. C'est moins spectaculaire dans une démo marketing, mais c'est probablement plus juste pour des gamins de huit ans.\r\n\r\nReste à voir ce que ça donne en vrai, sur le tapis du salon, après six mois d'utilisation, quand la batterie sera moins fringante et que la nouveauté se sera émoussée. C'est toujours là que se joue la vraie partie pour ce genre de produit. Mais sur le papier, et c'est rare, LEGO a sorti quelque chose qui ne ressemble à rien d'autre."},{"uuid":"cfe738e9-7ac2-4c7e-9205-dab4957835c6","slug":"preparation-du-raspberry-pi","title":"Décoder les infos de la TIC et les communiquer","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-19 06:48","created_at":"2025-11-19 06:48:01","updated_at":"2026-05-12 17:38:19","tags":[],"plain":"Choix du Raspberry Pi\r\n\r\nL'objectif est de récupérer automatiquement et à intervalles réguliers les informations émises par un compteur Linky, puis de les rendre accessibles depuis l'extérieur du Raspberry Pi.\r\n\r\nTrois prérequis matériels s'imposent donc :\r\nune connexion réseau, pour exposer ou transmettre les données collectées ;\r\nun espace de stockage, suffisant pour l'OS, les outils et l'historique des relevés ;\r\nune liaison série, pour dialoguer avec la sortie TIC du compteur.\r\n\r\nLe choix s'est porté sur un Raspberry Pi 3, qui couvre ces trois besoins sans surcoût ni complexité supplémentaire. Le stockage est assuré par une carte SD, la liaison série est exposée sur le port GPIO, et la connectivité réseau bénéficie d'un atout pratique : l'armoire de brassage de la maison se trouve à quelques mètres du compteur électrique, ce qui permet d'envisager un raccordement filaire fiable plutôt qu'un lien sans fil.\r\n\r\nCôté logiciel, le système retenu est Raspberry Pi OS (anciennement Raspbian), recommandé par défaut sur cette plateforme. Cette distribution dérivée de Debian apporte tout l'écosystème GNU/Linux nécessaire : pile réseau TCP/IP, accès distant par SSH, synchronisation horaire NTP, gestion de bases de données, serveur web, interpréteurs PHP et Python. Autant de briques qui serviront aux étapes ultérieures du projet.\r\n\r\nCâblage\r\n\r\nLe compteur Linky émet la trame TIC sous forme d'un signal modulé en ASK (Amplitude Shift Keying). Ce signal n'est pas directement exploitable par l'UART du Raspberry Pi, qui attend un niveau logique TTL stable.\r\n\r\nUn démodulateur ASK est donc intercalé entre le compteur et le Raspberry Pi. Son rôle est de récupérer la porteuse modulée et de restituer en sortie un signal binaire TTL propre, directement lisible par le port série.\r\n\r\nLa chaîne complète est la suivante :\r\n\r\n\r\n\r\nLe câblage côté Raspberry Pi se résume à trois fils :\r\nBroche | Signal | Rôle |\r\n---|---|---|\r\nPin 1 | 3V3 | Alimentation du démodulateur |\r\nPin 6 | GND | Masse commune |\r\nPin 10 | RX (GPIO15) | Lecture de la sortie TTL du démodulateur |\r\n\r\nSchéma de câblage\r\n\r\n\r\n\r\nInstallation de l'OS\r\n\r\nLe déploiement de Raspberry Pi OS sur la carte SD suit la procédure standard décrite dans l'article [à compléter]. Un point d'attention : activer le service SSH dès la préparation de l'image, faute de quoi aucun accès distant ne sera possible au premier démarrage.\r\n\r\nUne fois le Raspberry Pi mis sous tension et raccordé au réseau, son adresse IP n'est pas connue à l'avance. Un balayage du réseau local avec  permet de l'identifier :\r\nNote : la cible passée à  est l'adresse du réseau (), pas celle de la passerelle. Le  indique le masque de sous-réseau et délimite la plage scannée.\r\n\r\nUne fois l'adresse repérée, la connexion s'établit avec le compte  et le mot de passe par défaut  :\r\nPremier réflexe sécurité : changer immédiatement le mot de passe du compte  avec , voire désactiver ce compte au profit d'un utilisateur dédié. Les identifiants par défaut sont connus de tous les scans automatisés."}]