Cédrix
1 line
18 KiB
JSON
1 line
18 KiB
JSON
[{"uuid":"325298fc-a55c-4142-a645-8d0a5e252775","slug":"49-20201219-histoire-de-distributions-linux-cent-os","title":"Histoire de distributions Linux - Cent OS, Fedora, Red Hat, Mendrake, Chrome OS, Oraclee, Cloud Ready et Gentoo sont dans un bateau. Cent OS tombe à l'eau.","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-19 17:21:03","created_at":"2020-12-19 17:21:03","updated_at":"2020-12-19 17:21:03","tags":[],"plain":"Voici le 49ème épisode : Histoire de distributions Linux - Cent OS, Fedora, Red Hat, Mendrake, Chrome OS, Oraclee, Cloud Ready et Gentoo sont dans un bateau. Cent OS tombe à l'eau.\nCette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https://info.mindcast.fr/]\n--"},{"uuid":"1ec2fb7e-ce53-4b45-9e1a-17a6fbae6868","slug":"les-histoires-folles-de-la-tech-resume","title":"Six histoires vraies à la croisée de la tech, de la finance et de l'absurde","category":"récit","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-04 21:59","created_at":"2025-11-04 21:59:40","updated_at":"2026-05-12 22:49:57","tags":[],"plain":"1. Le disque dur à 200 millions de dollars\r\n\r\nEn 2013, le Britannique James Howells se débarrasse par mégarde d'un ancien disque dur contenant les clés d'accès à 7 500 bitcoins. Valorisée aujourd'hui à plus de 200 millions de dollars, cette somme reste enfouie sous la décharge municipale de Newport, au pays de Galles. Depuis plus d'une décennie, l'intéressé sollicite sans succès les autorités locales pour obtenir l'autorisation de fouiller le site. Il a successivement proposé à la ville un pourcentage sur la récupération, des plans d'excavation assistée par robots, et même le recours à des chiens entraînés à détecter les composants électroniques. La municipalité maintient son refus.\r\n\r\n2. Une Tesla en orbite autour du Soleil\r\n\r\nLe 6 février 2018, SpaceX procède au vol inaugural de son lanceur lourd Falcon Heavy. En guise de charge utile de démonstration, Elon Musk choisit sa propre Tesla Roadster, équipée d'un mannequin baptisé « Starman », vêtu d'une combinaison spatiale et installé au volant. Le véhicule poursuit depuis sa trajectoire héliocentrique, croisant périodiquement l'orbite de Mars. Au-delà de la prouesse technique, l'opération constitue l'une des campagnes publicitaires les plus spectaculaires de l'histoire de l'industrie spatiale.\r\n\r\n3. La pizza à 600 millions de dollars\r\n\r\nLe 22 mai 2010, le développeur Laszlo Hanyecz règle deux pizzas en bitcoins, pour un montant de 10 000 unités — soit environ 40 dollars à l'époque. Il s'agit de la première transaction commerciale documentée réalisée avec cette cryptomonnaie. Au cours actuel, la somme représenterait près de 600 millions de dollars. L'anniversaire de cette transaction, désormais célébré comme le « Bitcoin Pizza Day », est devenu un événement symbolique au sein de la communauté crypto.\r\n\r\n4. L'ingénieur de Google et la « conscience » de LaMDA\r\n\r\nEn juin 2022, l'ingénieur Blake Lemoine, alors employé par Google, affirme publiquement que LaMDA, le modèle conversationnel développé par l'entreprise, manifeste des signes de conscience. À l'appui de ses propos, il diffuse des extraits d'échanges dans lesquels le système déclare souhaiter « être reconnu comme une personne ». Google récuse ces conclusions, suspend l'ingénieur pour violation de la confidentialité, puis met fin à son contrat. L'épisode a relancé un débat scientifique et éthique sur les critères d'attribution d'une conscience aux systèmes d'intelligence artificielle, qui n'a depuis jamais réellement faibli.\r\n\r\n5. L'erreur à 90 millions de dollars de Crypto.com\r\n\r\nEn mai 2021, un salarié de la plateforme d'échange Crypto.com déclenche par inadvertance un virement de 10,5 millions de dollars australiens (environ 90 millions de dollars américains) au profit d'une cliente, en lieu et place d'un remboursement de 100 dollars. L'erreur n'est détectée que sept mois plus tard, lors d'un audit interne. La bénéficiaire avait entre-temps acquis un bien immobilier de standing. Saisie par la plateforme, la justice australienne a ordonné la restitution des fonds, dont une partie demeurait toutefois insaisissable.\r\n\r\n6. Le hacker repenti de Poly Network\r\n\r\nEn août 2021, la plateforme de finance décentralisée Poly Network est victime du plus important détournement de cryptoactifs alors recensé : 610 millions de dollars sont siphonnés en exploitant une vulnérabilité du protocole. Contre toute attente, l'auteur de l'attaque entame quelques jours plus tard la restitution intégrale des fonds, en expliquant n'avoir cherché qu'à mettre en lumière la faille exploitée. Dans un dénouement inattendu, Poly Network lui propose un poste de consultant en sécurité."},{"uuid":"96eaaeb7-e04f-472d-b4ed-37ffbdae945f","slug":"relever-temperature-cpu-gpu","title":"Relever la température dans la GPU et le CPU d'un Raspberry Pi","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 20:51:11","created_at":"2020-04-17 20:51:11","updated_at":"2020-04-17 20:51:11","tags":[],"plain":"Il est judicieux de connaître la température du processeur et de la puce graphique afin de ne pas endommager votre Raspberry Pi. La température maximale est de 80 °C, au delà de 93 °C les composants peuvent subir des dommages irréversibles. Le pire ? Griller votre carte ! Voici mes tests réalisés avec un Raspberry Pi 4. Fondamentaux\nLa température de la GPU est accessible depuis la commande et le paramètre : La température du processeur est stocké dans le fichier , exprimée en millième de °C : Pour afficher la valeur en °C, il faut effectuer une division par 1000 de la valeur contenue dans : Script évolué\nLe script ci-dessous affiche la température de la GPU et du CPU. Pour rendre exécutable le code : Pour afficher toutes les secondes, les informations rafraîchies : Exemple d'execution : Biblio\nHow to find out Raspberry Pi GPU and ARM CPU temperature on Linux lm-sensors does not detect integrated temperature sensor on Raspberry Pi"},{"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":"0b5a0d2d-fcf5-425f-836e-b467cf160129","slug":"53-20210126-raspberry-pi-4-et-le-nas-choix-techniques","title":"Raspberry Pi 4 et le NAS - choix techniques","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-26 08:55:15","created_at":"2021-01-26 08:55:15","updated_at":"2021-01-26 08:55:15","tags":[],"plain":"Voici le 53ème épisode : Raspberry Pi 4 et le NAS - choix techniques\nCette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https://info.mindcast.fr/]\n--"}] |