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

L’IA est-elle en train de tuer l’Open Source ?

Mon, 19 Jan 2026 09:34:59 +0100 - (source)

IA par-ci, IA par-là.. même ceux qui critiquent l'IA générative, s'en servent pour faire leurs posts de blog remplis de fake blabla. Mais cette fois on touche un peu au nerf de la guerre, puisque Daniel Stenberg, le créateur de Curl, a lancé son petit cri d'alarme la semaine dernière.

Curl est un outil qui est dispo dans à peu près tous les systèmes qui ont une adresse IP et le problème de Daniel c'est que son projet reçoit de TROP nombreux rapports de sécurité bidon générés à la chaîne par des LLM.

Du coup, ça lui fait perdre pas mal de temps ainsi qu'aux mainteneurs du projet, pour trier le bon grain de l'ivraie

C'est tellement critique qu'il envisage sérieusement de fermer son programme de Bug Bounty... Bref, ça craint pour l'avenir de la collaboration autour de l'open source.

Une fois encore, et au risque de me répéter, le problème n'est pas l'outil. l'IA est une super aide pour analyser du code mais quand on y ajoute une incitation financière (un bounty quoi), ça devient la fête à la paresse intellectuelle. Des "chasseurs de primes" sans compétences, s'emparent alors de scripts à base d'IA pour scanner des repos et copient collent les rapports sans les lire.

L'idée pour eux, c'est qu'en faisant ça massivement, ils grapillent un petit peu de sous.

Et de ce que j'ai compris, Curl n'est pas le seul projet à vivre ce calvaire. Par exemple, Godot (le moteur de jeu) a lui aussi dû prendre des mesures contre ce genre de contributions GenAI, et ça s'inquiète aussi beaucoup du côté du noyau Linux...

Tous ces petits indices me font donc me demander quel est l'impact réel de l'IA sur l'open source... Parce que d'un côté, c'est quand même une super aide. Ça abaisse la barrière à l'entrée. Ça permet de voir des choses qu'un humain n'aurait pas forcément vues. Mais d'un autre côté, ça inonde les mainteneurs de projets sous un tas de rapports "slop" (C'est LE mot à la mode pour désigner du contenu merdique fait par IA ^^) contenant des failles imaginaires ou cassant des fonctionnalités existantes.

Bref, c'est un peu la merde parce que les mainteneurs de repos sont en train de vriller parano, à fliquer les contributeurs au lieu de collaborer, et je trouve que ça casse un peu l'essence même de l'open source qui est la confiance et la réputation.

Quand vous poussez un bon gros commit, vous annoncez aux barbus en rute que c'est votre boulot, avec du vrai jus de cervelle derrière. Mais si c'est un LLM qui a tout pondu et que vous n'avez même pas relu, vous n’êtes plus un contributeur : vous êtes juste un spammeur.

Alors on fait quoi ?

On revient comme dans les années 90 avant l'IA, par pur "Oui mais moi j'ai des principes", ou est-ce qu'on apprend à utiliser ces modèles comme des assistants et on commence à s'éduquer les uns les autres pour essayer de faire de la qualité en remettant l'humain dans la boucle ?

Moi je trouve que l'IA générative c'est génial, mais je trouve aussi que les gens l'utilisent mal, et c'est ça qui produit ce slop en fait. Et je trouve ça con parce qu'on pourrait aller tellement plus loin si les gens apprenaient à collaborer avec l'IA au lieu de juste s'en servir pour pouvoir regarder Netflix pendant que ça bosse...

Donc les amis, si vous utilisez une IA pour trouver un bug, il n'y a pas de soucis avec ça (c'est mon point de vue évidemment), mais au moins vérifiez-le, rejouez-le, essayez de le comprendre, sinon bah abstenez-vous quoi.

Et si ce sujet de la gouvernance des projets libres vous plaît, je vous invite à jeter un œil aux discussions sur les bannissements dans le noyau Linux . Rappelez-vous aussi de "l'incident" de la backdoor XZ Utils qui aurait pu très mal tourner...

L'open source et le libre, c'est fragile et il faut en prendre soin.

Sourc e


Loopmaster - Faites de musique électro en codant directement dans votre navigateur

Mon, 19 Jan 2026 09:00:00 +0100 - (source)

Si vous avez déjà vu des vidéos d'algorave, ces soirées où des mecs font danser des foules entières en tapant des lignes de code sur un écran géant, vous savez de quoi je parle. Le live coding musical, c'est hypnotique, c'est technique, et ça donne des résultats sonores assez dingues.

Le problème, c'est que jusqu'ici, pour s'y mettre, fallait souvent s'infuser l'installation de trucs comme Sonic Pi ou TidalCycles . C'est génial, mais faut configurer l'environnement, les serveurs audio, et là, bam, la flemme pointe le bout de son nez. C'est là qu'intervient Loopmaster , un projet passion qui permet de faire exactement la même chose, mais directement dans votre navigateur.

Vous débarquez sur le site, vous écrivez du code, vous appuyez sur Entrée, et ça fait de la musique, en temps réel, sans avoir besoin d'installer quoi que ce soit. Tout se passe sous vos yeux grâce à la magie des APIs audio de votre navigateur. Wololo !

L interface de Loopmaster - sobre et efficace ( Source )

C'est une façon complètement différente d'aborder la création sonore car au lieu de cliquer fébrilement sur des boutons et de manipuler des faders virtuels, vous décrivez ce que vous voulez entendre avec des algorithmes. Un pattern rythmique devient alors une boucle dans votre script, un synthé devient une fonction, et une progression d'accords devient une simple liste de valeurs.

Le truc vraiment cool, c'est que comme c'est du code, vous pouvez faire des choses impossibles autrement. Du genre des patterns qui évoluent mathématiquement, de rythmes générés par des probabilités, ou de textures sonores qui se transforment selon des règles que vous définissez vous-même.

Loopmaster n'est pas le seul sur le créneau, y'a aussi Strudel, mais il a cet avantage d'être hyper accessible pour débuter. Et cerise sur le gâteau pour les producteurs, une fois que vous avez pondu une boucle qui déchire, vous pouvez exporter l'audio pour l'importer ensuite dans votre DAW préféré comme Ableton Live. Nickel pour enrichir vos prods avec des sonorités algorithmiques uniques.

Bref, si vous avez 10 minutes à tuer et que vous voulez vous prendre pour un sorcier du son, allez jeter un œil. Au pire, vous passerez pour un génie incompris auprès de vos collègues en faisant du bruit bizarre, au mieux vous découvrirez une nouvelle passion pour l'algorave.

Et si le sujet vous branche, j'avais déjà parlé de comment coder de la musique avec Sonic Pi ou encore de Polymath pour les plus curieux.

Allez, kiffez bien et faites péter les basses !


Je suis complètement passé à côté parce que j'avais la tête dans le guidon mais est ce que vous vous souvenez de PearOS ?

C'était cette distribution Linux qui essayait de copier macOS jusqu'au moindre pixel et qui disparaissait tous les deux ans dès qu'Apple commençait à froncer les sourcils.

Hé bien la poire est de retour et cette fois, elle a mangé du lion !

Le nouveau cru de ce clone de macOS a troqué sa vieille base Debian pour une base Arch Linux toute neuve baptisée NiceC0re. Et là, on est sur de la distribution en rolling release, donc toujours à jour, avec un noyau 6.17 sous le capot. C'est donc une vraie petite machine Linux qui ne demande qu'à ronronner sur vos vieux laptops.

L'interface est quand même le coeur du truc et je la trouve plutôt bien réussi... C'est à base de KDE Plasma 6.5.3 mais ils l'ont tellement bidouillé qu'on jurerait être devant un Mac d'il y a quelques années. Ils appellent ça le "Liquid Gel Design". Bon, le nom fait un peu gel douche pour geek, mais le résultat visuel est juste mortel ! Tout est fluide, les animations glissent toutes seules et les effets de flou sont partout.

Du coup, on retrouve tout ce qui fait le sel de Cupertino, à savoir le Dock en bas, la barre de menus en haut, et même un "PearFinder" pour chercher ses fichiers. Y'a aussi une extension de panneau qui imite le Launchpad et un KRunner boosté qui joue le rôle de Spotlight.

Donc si vous cherchez comment transformer votre PC en Mac sans dépenser un SMIC, vous tenez peut-être la solution...

C'est marrant de voir que malgré les années, l'envie d'avoir un "macOS libre" est toujours aussi forte. On l'a vu avec ce macOS emprisonné dans Linux , mais ici l'approche est plus intégrée puisqu'on ne virtualise pas mais on remplace carrément le système. Et avec la stabilité d'Arch, ça pourrait presque devenir une machine de prod pour ceux qui aiment l'ergonomie d'Apple mais détestent leur politique fermée.

Bref, si vous avez une vieille bécane qui traîne au fond d'un tiroir et que vous voulez lui redonner un coup de jeune avec une interface qui claque, jetez un œil à ce système basé sur Arch.

C'est pas encore parfait mais c'est prometteur de ouf.


Cet article fait partie de ma série spéciale hackers . Bonne lecture !

Un gamin de 15 ans qui pète les serveurs de la NASA pendant que moi, à son âge, j'en était encore à configurer mon modem 56k pour qu'il arrête de faire du bruit en pleine nuit... Jonathan James, alias c0mrade, est devenu le premier mineur emprisonné pour cybercriminalité aux États-Unis... avant, malheureusement, de se suicider à 24 ans parce qu'il pensait qu'on allait l'accuser d'un crime qu'il n'avait pas commis.

Voici l'histoire la plus dingue et la plus tragique du hacking que vous n'avez jamais entendue.

Jonathan Joseph James naît le 12 décembre 1983 à Pinecrest, un quartier cossu de Miami-Dade County. Son père, Robert James, bosse comme programmeur pour le comté... déjà, on sent que l'informatique, c'est de famille. Sa mère, Joanne Jurysta, tient la maison pendant que les deux frangins, Jonathan et Josh, grandissent dans un environnement de classe moyenne supérieure.

Dès 6 ans, Jonathan passe ses journées sur l'ordinateur paternel. Au début, c'est pour jouer, évidemment. Mais très vite, le gamin comprend qu'il peut faire bien plus que lancer des jeux. Il commence à triturer, à fouiller, à comprendre comment ça marche sous le capot. Ses parents, inquiets de voir leur fils scotché à l'écran, décident alors de lui confisquer l'ordinateur quand il atteint ses 13 ans.

Grosse erreur.

Car Jonathan fait une fugue. Il refuse catégoriquement de rentrer à la maison tant qu'on ne lui rend pas son accès à l'informatique. J’imagine la scène avec ces parents complètement dépassés face à un ado qui préfère dormir dehors plutôt que de vivre sans son ordinateur. Bon, ils finissent par craquer, évidemment.

C'est à cette époque que Jonathan se forge son identité de hacker. Il choisit l'alias c0mrade avec un zéro à la place du 'o', parce que dans les années 90, remplacer des lettres par des chiffres, c'était le summum du cool.

Et surtout, il passe ses nuits sur les BBS et les premiers forums de hacking, à échanger avec une communauté underground qui n'a absolument rien à voir avec les script kiddies d'aujourd'hui. C'est une époque où pirater demandait de vraies compétences techniques, pas juste télécharger un exploit sur GitHub.

L'été 1999. Jonathan a 15 ans, les cheveux longs, et une curiosité maladive pour tout ce qui ressemble à un serveur mal configuré. Entre le 23 août et le 27 octobre 1999, il va commettre une série d'intrusions qui vont faire de lui une légende du hacking... et accessoirement, le faire finir en prison.

Pour son méfait, le gamin scanne les réseaux à la recherche de serveurs Red Hat Linux mal patchés et comme en 1999, la sécurité informatique, c'est encore le Far West, les administrateurs système pensent que mettre leur serveur derrière un firewall basique, c'est suffisant.

Sauf que ça ne l'était pas.

Jonathan exploite des vulnérabilités connues pour installer des backdoors c'est à dire des portes dérobées qui lui permettent de revenir à volonté sur les systèmes compromis. Mais le plus fort, c'est qu'il installe aussi des sniffers réseau, des programmes qui interceptent tout le trafic qui passe par le serveur. Mots de passe, emails, données sensibles... tout y passe.

Sa première cible d'envergure ? BellSouth, le géant des télécoms. Puis le système informatique des écoles de Miami-Dade County. Mais c'est quand il s'attaque aux agences gouvernementales que les choses deviennent vraiment intéressantes.

En septembre 1999, c0mrade détecte une backdoor sur un serveur situé à Dulles, en Virginie. Au lieu de passer son chemin, il décide d'aller voir de plus près. Il se connecte, installe son sniffer maison, et se rend compte qu'il vient de compromettre un serveur de la DTRA, c'est à dire la Defense Threat Reduction Agency, une division ultra-sensible du Département de la Défense qui s'occupe d'analyser les menaces NBC (nucléaires, biologiques, chimiques) contre les États-Unis.

Pendant plusieurs semaines, Jonathan intercept plus de 3300 emails entre employés de la DTRA. Il récupère aussi des centaines d'identifiants et mots de passe, ce qui lui permet d'accéder à une dizaine d'ordinateurs militaires supplémentaires. Tout ça sans que personne ne s'en aperçoive.

Mais le clou du spectacle, c'est son intrusion chez NASA.

En juin 1999, Jonathan tombe sur un serveur mal configuré à Huntsville, Alabama. Il l'infecte avec son malware habituel et découvre qu'il vient de compromettre le Marshall Space Flight Center de la NASA. Et c'est pas n'importe lequel puisque c'est celui qui développe les moteurs de fusée et les logiciels pour la Station Spatiale Internationale.

En installant sa backdoor, c0mrade réalise qu'il peut accéder à 12 autres ordinateurs du réseau. Et là, jackpot ! Il met la main sur le code source d'un programme qui contrôle des éléments critiques de l'ISS. On parle du système de contrôle de la température et de l'humidité dans les modules habitables de la station spatiale.

Rien que ça...

Jonathan télécharge l'intégralité du logiciel. Valeur estimée par la NASA : 1,7 million de dollars. Mais attention, ce n'est pas un vol dans le sens classique du terme puisque le gamin ne revend rien, ne détruit rien, ne modifie rien. Il copie, point. Sa philosophie de grey hat hacker de l'époque c'est d'explorer sans nuire.

Sauf que quand la NASA découvre l'intrusion, et ça devient vite la panique à bord. L'agence spatiale est obligée de couper ses serveurs pendant 21 jours pour vérifier l'intégrité de ses systèmes et colmater les failles. Coût de l'opération : 41 000 dollars de plus. Pour l'époque, c'est énorme.

Encore une fois, on réalise à quel point la sécurité de nos infrastructures critiques tenait du miracle en 1999.

Nous sommes le 26 janvier 2000. Jonathan vient d'avoir 16 ans depuis quelques semaines. Il est tranquillement dans sa chambre quand des agents fédéraux débarquent chez lui avec un mandat de perquisition. FBI, NASA, Département de la Défense... tout le gratin de la sécurité nationale américaine vient cueillir le gamin de Miami. Comme l'a rapporté ABC News à l'époque , l'arrestation fait sensation dans les médias.

Jonathan ne fait même pas semblant de nier. Plus tard, il expliquera aux enquêteurs qu'il aurait pu facilement couvrir ses traces s'il avait voulu. Mais il ne pensait pas faire quelque chose de mal. Dans sa tête d'ado, il "jouait" juste avec des ordinateurs. Il n'avait volé aucune donnée pour s'enrichir, n'avait planté aucun système, n'avait rien détruit.

Le problème c'est que la justice américaine ne voit pas les choses du même œil.

Le 21 septembre 2000, Jonathan James devient alors officiellement le premier mineur condamné à une peine de prison pour cybercriminalité aux États-Unis. À 16 ans, il entre dans l'histoire du droit pénal informatique. Et sa sentence est de 7 mois d'assignation à résidence, probation jusqu'à ses 18 ans, et interdiction d'utiliser un ordinateur à des fins "récréatives".

Mais Jonathan est un ado. Il est positif à un contrôle antidrogues (cannabis) et viole ainsi sa probation. Direction la prison fédérale de l'Alabama pour 6 mois supplémentaires. Le gamin qui piratait la NASA depuis son lit se retrouve derrière les barreaux.

L'ironie, c'est que son cas va complètement révolutionner la législation sur la cybercriminalité juvénile. Avant Jonathan, les juges ne savaient littéralement pas comment traiter un mineur capable de compromettre des systèmes gouvernementaux. Son procès a forcé le Congrès à repenser les lois fédérales sur les crimes informatiques commis par des mineurs.

Jonathan sort de prison en 2001. Il a 17 ans, un casier judiciaire, et une réputation sulfureuse dans le milieu du hacking et il essaie de se tenir à carreau, de mener une vie normale. Mais son passé va le rattraper de la pire des manières.

En 2007, la chaîne de magasins TJX (TJ Maxx, Marshalls, HomeGoods) subit l'une des plus grosses fuites de données de l'histoire : 45,6 millions de numéros de cartes de crédit volés. L'enquête mène à Albert Gonzalez , un hacker de Miami qui dirigeait un réseau international de cybercriminels, selon le département de la Justice américain .

Source

Mais le problème c'est qu'Albert Gonzalez et Jonathan James se connaissent. Ils évoluent dans les mêmes cercles, fréquentent les mêmes forums, habitent la même région. Alors quand le FBI épluche les connexions de Gonzalez, le nom de c0mrade ressort forcément.

En janvier 2008, le Secret Service débarque chez Jonathan, chez son frère, chez sa copine. Ils retournent tout, confisquent ses ordinateurs, l'interrogent pendant des heures. Jonathan nie catégoriquement toute implication dans le hack TJX. Il répète qu'il n'a plus fait de hacking depuis sa sortie de prison, qu'il essaie de refaire sa vie.

Les agents trouvent une arme à feu légalement détenue et des notes suggérant que Jonathan a déjà pensé au suicide. Mais aucune preuve de sa participation au hack TJX.

Pourtant, l'étau se resserre. La presse s'empare de l'affaire, ressort son passé de "hacker de la NASA". Jonathan devient paranoïaque, convaincu que le gouvernement veut faire de lui un bouc émissaire. Il sait qu'avec son casier, aucun jury ne croira en son innocence.

Alors le 18 mai 2008, Pinecrest, Floride, Jonathan James, 24 ans, se tire une balle dans la tête sous la douche de sa salle de bain.

Il laisse une note déchirante : "Je n'ai honnêtement, honnêtement rien à voir avec TJX. Je n'ai aucune foi dans le système de 'justice'. Peut-être que mes actions d'aujourd'hui, et cette lettre, enverront un message plus fort au public. De toute façon, j'ai perdu le contrôle de cette situation, et c'est ma seule façon de le reprendre."

La suite lui donnera raison : Albert Gonzalez sera condamné à 20 ans de prison, mais aucune preuve ne sera jamais trouvée contre Jonathan James concernant l'affaire TJX.

Ce gamin était un génie pur. Pas le genre de génie qu'on voit dans les films, mais un vrai génie technique, capable de comprendre et d'exploiter des systèmes complexes à un âge où la plupart d'entre nous découvraient à peine Internet.

Le problème, c'est que personne n'a su canaliser ce talent. Ses parents ont essayé de le brider en lui confisquant son ordinateur. Le système judiciaire l'a traité comme un criminel ordinaire. Et la communauté du hacking de l'époque n'avait pas vraiment de garde-fous éthiques.

Et aujourd'hui, combien de c0mrade potentiels traînent-ils sur nos serveurs Discord, nos repos GitHub, nos communautés de makers ?

Maintenant on a des programmes de bug bounty, des certifications en cybersécurité, des bootcamps éthiques. Des voies légales pour exprimer ce genre de talent. Alors que Jonathan n'a jamais eu ces options.

Son héritage, comme celui de Kevin Mitnick , c'est donc d'avoir forcé le monde à prendre la cybersécurité au sérieux. Après ses exploits, la NASA a complètement revu ses protocoles de sécurité, le Pentagone a investi des milliards dans la protection de ses systèmes et le Congrès a voté de nouvelles lois sur la cybercriminalité juvénile.

Je pense que Jonathan James aurait mérité mieux que cette fin tragique. Il aurait pu devenir un expert en cybersécurité, un consultant, un formateur. Il aurait pu utiliser ses compétences pour protéger les systèmes qu'il avait appris à compromettre... C'est triste.

A nous de faire en sorte que les prochains génies du code ne suivent pas le même chemin.

Source


J'espère que vous passez une bonne semaine et que votre connexion internet ne vous fait pas trop la misère en ce moment...

Car aujourd'hui, on va parler d'un truc qui devrait intéresser tous ceux qui utilisent un VPN (ou qui pensent en utiliser un, un jour) pour leurs activités un peu... gourmandes en bande passante. Vous le savez, je le sais, BitTorrent c'est génial, mais c'est aussi un moyen facile de se retrouver avec son adresse IP exposée aux trackers et aux pairs du swarm. Et même avec un tunnel sécurisé, on peut toujours être victime d'une fuite en cas de mauvaise configuration ou de rupture du VPN.

Et là, y'a toujours Hadopi (enfin, ce qu'il en reste) qui pour justifier leur budget annuel vous enverra un petit message de menace automatique. Pas de communication non violente ici ^^.

C'est précisemment là qu'intervient Torrent Peek , un petit outil qui est gratuit et sans inscription et qui va vous permettre de vérifier si votre protection est efficace ou si elle laisse filtrer votre IP. Pour cela, le site génère un lien magnet unique que vous ouvrez dans la plupart des clients torrent (uTorrent, Transmission, Deluge, etc.).

Une fois le lien ajouté, votre client va tenter de se connecter aux trackers du site, et hop ! Torrent Peek affichera alors l'adresse IP qu'il voit passer. Si c'est celle de votre VPN, c'est un bon signe. Si c'est votre vraie IP... eh bien vous êtes dans la mierda ^^.

Car même avec un VPN actif, une défaillance du "kill switch" ou un trafic qui sort du tunnel peut exposer votre identité réelle. Notez d'ailleurs que l'exposition peut aussi se faire via DHT ou PEX, ce que ce test ne couvre pas forcément, mais c'est déjà une excellente première vérification côté trackers.

Le truc cool avec cet outil, c'est qu'il propose aussi une API JSON pour ceux qui aiment bien automatiser leurs tests ou surveiller leur connexion via un petit script maison. Il suffit de faire un petit curl sur l'URL fournie pour obtenir le statut de votre connexion à l'instant T.

D'ailleurs, si vous voulez aller plus loin dans la bidouille torrentielle, je vous recommande de jeter un œil à cet article pour ouvrir des liens magnet directement avec VLC (moyennant un petit plugin), car c'est super pratique.

Voilà, ça vous permettra de vérifier que vous ne faites pas n'importe quoi quand vous téléchargez des ISO Linux toute la nuit 😅...


Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?

Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !

Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !

Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env ( Source )

Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap .

C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).

Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.

Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.

Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.

D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur SOPS ou encore ma réflexion sur l'usage de GitLab pour vos projets sensibles.

Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !


OGhidra - Dopage à l'IA pour Ghidra en local

Sat, 17 Jan 2026 16:52:56 +0100 - (source)

Les gars de chez LLNL (Lawrence Livermore National Laboratory) sont des bons ! De vrais spécialistes en sécurité informatique qui ont pondu un outil à essayer si vous passez vos journées dans les entrailles des binaires.

Ça s'appelle OGhidra , et c'est une extension qui fait le pont entre le célèbre framework de reverse engineering Ghidra et la puissance des modèles de langage (LLM).

Comme ça, plutôt que de vous péter les yeux sur des milliers de lignes de code décompilé, vous pouvez simplement "discuter" avec les fonctions ou les strings extraites. Grâce à une intégration avec Ollama, OGhidra permet d'interroger les représentations du binaire en langage naturel pour identifier des vulnérabilités, renommer intelligemment des fonctions ou expliquer des algorithmes complexes. Attention toutefois, comme avec tout LLM, les résultats doivent être validés manuellement (les hallucinations, ça arrive même aux meilleurs !).

Le gros avantage ici, vous l'aurez compris, c'est la privacy car tout tourne en local sur votre ordi. L'extension utilise des techniques comme le RAG (Retrieval-Augmented Generation) pour garder le contexte de vos sessions et le CAG (Cache-Augmented Generation) pour optimiser les performances. Prévoyez quand même une machine solide car pour faire tourner des modèles comme gemma3 confortablement, 32 Go de RAM (et une bonne dose de VRAM) ne seront pas de trop.

Pour que ça envahisse vos machines de reverse engineer, il vous faudra Ghidra 11.3 minimum et JDK 17. L'installation se fait ensuite en deux temps : d'abord le plugin GhidraMCP à ajouter dans Ghidra, puis le composant Python à récupérer sur GitHub :

git clone https://github.com/LLNL/OGhidra.git
cd OGhidra
pip install -r requirements.txt

Une fois Ollama lancé avec vos modèles préférés, vous allez pouvoir automatiser les tâches les plus reloues. Par exemple grâce aux boutons "Smart Tool" dans l'interface de Ghidra vous allez pouvoir renommer toutes les fonctions d'un coup ou générer un rapport de sécurité (à prendre comme une base de travail, pas comme une vérité absolue, hein ^^).

C'est beau mais ça fait mal quand on pense au temps qu'on a perdu par le passé ! Et si vous kiffez ce genre d'approches, jetez aussi un œil à Cutter qui propose une intégration optionnelle du décompileur de Ghidra, ou encore à DecompAI .

Voilà, j'ai trouvé ça intéressant pour booster Ghidra avec une petite dose d'intelligence locale.


Si vous êtes du genre à avoir passé des heures sur Half-Life 2 à vous en retourner les paupières (et je sais que vous êtes nombreux), oubliez tout ce que vous pensiez savoir sur la stabilité légendaire du Source Engine. Car figurez-vous qu'un bug totalement improbable vient de refaire surface grâce à Tom Forsyth, un ancien de chez Valve, et c'est clairement un truc de fou, vous allez voir...

Tout commence en 2013. À l'époque, Valve bosse sur le portage de HL2 pour le tout premier Oculus Rift (le fameux DK1 qui nous donnait tous envie de vomir au bout de 5 minutes). Pour tester la VR, ils se disent que le mieux, c'est de reprendre un bon vieux classique. Tout se passe bien jusqu'à ce que Tom Forsyth reste bloqué dès l'intro du jeu, juste après la séquence de la canette. Un garde Barney censé vous ouvrir une porte reste planté là, et la porte refuse de bouger. Coincé. Rideau. On ferme.

Le truc qu'il constate alors, c'est qu'en recompilant le code source original de 2004, le bug est là aussi ! Pourtant, personne ne l'avait jamais croisé en neuf ans. Du coup, l'équipe a cru à une sorte de malédiction ou à un bug qui aurait voyagé dans le temps pour infecter l'original. (si si...)

Mais après une journée de spéléologie dans les outils de debug, ils ont fini par trouver le coupable : l'orteil d'un garde PNJ ! Le pauvre couillon était placé un millimètre trop près de la porte et en s'ouvrant, la porte tapait dans son pied, rebondissait et se verrouillait. Imaginez un peu la vie du gars, à se faire matraquer l'orteil depuis +20 ans sans pouvoir crier ou se décaler d'un millimètre... Dur !

Mais alors pourquoi ça marchait en 2004 et plus en 2013 ?

Hé bien la réponse tient en deux mots qui vont rappeler des souvenirs aux plus geeks d'entre vous : ✨ virgule flottante ✨.

Car en 2004, le jeu tournait avec les instructions x87 (80 bits de précision, un beau bordel hérité de l'époque)et en 2013, avec le passage au SSE (32 ou 64 bits), les calculs physiques sont devenus plus "stricts". Dans les deux versions, la porte tape l'orteil mais avec le x87, la micro-rotation infligée au garde suffisait à dégager son pied juste assez pour que la porte passe au millième de seconde suivant. Avec le SSE par contre, le garde pivotait un chouïa moins loin... et paf, collision, porte bloquée !

C'est encore une preuve que même dans un chef-d'œuvre comme Half-Life 2, tout ne tient qu'à un orteil et quelques bits. D'ailleurs, si vous voulez vous replonger dans l'ambiance, sachez que Half-Life a fêté ses 25 ans récemment avec une belle mise à jour, et pour les nostalgiques de la VR qui veulent souffrir avec style, le driver VorpX permet toujours de faire des miracles. Ce serait dommage de passer à côté !

Allez, je vous laisse, je vais vérifier si mon gros orteil ne bloque pas ma porte d'entrée.

Source


OK les amis, là faut qu'on parle de ce qui se passe chez Rockstar. Je pense que vous passez probablement trop de temps à errer dans Los Santos au lieu de bosser, mais ce qui vient de tomber est bien plus inquiétant qu'un braquage de banque qui foire. En effet, d'après une enquête de Variety , Rockstar vient de supprimer des missions créées par des joueurs qui recréaient l'assassinat réel de Charlie Kirk, un fasciste américain tué en septembre dernier.

Le truc, c'est que ce n'est pas juste une petite polémique politique de plus. C'est LE SIGNE que Rockstar Games est en train de réaliser, un peu tard, qu'ils ne contrôlent plus leur propre bébé. Car même si les outils de création existent depuis 2013, une nouvelle fonctionnalité lancée en décembre dernier a visiblement boosté la créativité macabre de certains. Désormais, des joueurs s'improvisent game designer pour injecter des événements du monde réel directement dans le jeu sandbox de Rockstar.

Et là, c'est le drame ! Pour essayer de colmater les brèches, ils ont même dû repenser leur vieux "filtre de grossièretés" interne qui n'est plus juste là pour empêcher les gamins d'écrire des insultes dans le chat, mais pour modérer et bloquer massivement des noms de personnalités ou des événements sensibles. En gros, Rockstar est passé du statut de créateur de mondes virtuels à celui de modérateur de plateforme, un peu comme s'ils géraient un réseau social géant, mais avec des flingues et des bagnoles.

Certains se demandent si l'acquisition de Cfx.re (l'équipe derrière FiveM) en 2023 par Rockstar n'était pas justement un moyen de préparer le terrain avec des technos de contrôle plus musclées. Mais peu importe, car le vrai problème ici est structurel. GTA est devenu une plateforme UGC massive (User Generated Content) et quand on voit à quel point ils galèrent déjà, on peut légitimement se demander comment ils vont gérer le futur multi de GTA 6, prévu pour novembre 2026 ?

Sérieux, je m'inquiète car imaginez l'échelle du prochain titre avec des outils encore plus poussés... Ça va être un combat permanent pour supprimer les contenus problématiques. On est trèèèès loin de l'époque où on s'amusait simplement à regarder Los Santos sous l'eau grâce à un mod. Ici, Rockstar découvre à ses dépends que la liberté offerte aux joueurs est en train de se transformer en leur pire cauchemar de modération.

Allez, bon courage Rockstar, parce que là, vous allez en avoir besoin.

Source


Il y a des combats comme cela auxquels pas grand monde ne pense et qui pourtant sont très importants. Je parle évidemment de la lutte contre le chaos du texte non structuré. Si vous avez déjà essayé d'extraire des données propres d'un tas de PDF (après OCR), de rapports ou de notes griffonnées, vous voyez de quoi je parle : c'est l'enfer ! (oui j'aime me faire du mal en tentant des regex impossibles).

Heureusement, Google a lâché début janvier 2026 une petite pépite en open source (même si c'est pas un produit "officiel") qui s'appelle LangExtract . C'est une bibliothèque Python qui utilise la puissance des LLM pour transformer vos documents textuels en données JSON bien rangées.

Exemple d'extraction sur le texte de Roméo et Juliette ( Source )

Ce qui fait que LangExtract sort du lot par rapport à d'autres outils comme Sparrow , c'est surtout son système de Source Grounding. En gros, chaque info extraite est directement liée à sa position exacte dans le texte source. Ça facilite énormément la vérification et la traçabilité puisque vous pouvez voir visuellement d'où vient la donnée grâce à un système de surlignage automatique.

Sous le capot, l'outil est optimisé pour les documents à rallonge (le fameux problème de l'aiguille dans une botte de foin). Il utilise des stratégies de découpage de texte et de passes multiples pour améliorer le rappel et s'assurer que le maximum d'infos soit capturé.

La visualisation interactive permet de valider les données en un clin d'œil ( Source )

Et cerise sur le gâteau, il permet de générer un fichier HTML interactif pour visualiser les milliers d'entités extraites dans leur contexte original. À la cool !

Côté installation, c'est hyper fastoche :

pip install langextract

Pour faire le job, vous avez le choix des armes : les modèles cloud de Google (Gemini 2.5 Flash/Pro), ceux d'OpenAI (via pip install langextract[openai]), ou carrément du local avec Ollama . Pas besoin de passer des heures à fine-tuner un modèle, il suffit de fournir quelques exemples structurés via le paramètre examples et hop, c'est parti mon kiki.

Voici à quoi ça ressemble sous le capot pour lancer une machine à extraire :

import langextract as lx

# 1. On définit les règles du jeu
prompt = "Extraire les noms de personnages et leurs émotions."

# 2. On donne un exemple (few-shot) pour guider le modèle
examples = [
 lx.data.ExampleData(
 text="ROMEO. But soft! What light...",
 extractions=[lx.data.Extraction(extraction_class="character", extraction_text="ROMEO", attributes={"emotion": "wonder"})]
 )
]

# 3. On lance l'extraction (nécessite une clé API ou Ollama)
results = lx.extract(
 text_or_documents="votre_texte_brut_ici",
 prompt_description=prompt,
 examples=examples,
 model_id="gemini-2.5-flash"
)

# 4. On sauvegarde et on génère la visualisation HTML
lx.io.save_annotated_documents(results, output_name="results.jsonl")
html_content = lx.visualize("results.jsonl")
with open("view.html", "w") as f:
 f.write(html_content)

Honnêtement, je ne sais pas si ça va remplacer les solutions industrielles de RPA , mais pour un dev qui veut structurer du texte sans se prendre la tête, c'est vraiment impressionnant. Que vous fassiez du Grist ou de l'analyse de données pure, cet outil mérite clairement que vous y jetiez un œil !

Source


Powered by VroumVroumBlog 0.1.31 - RSS Feed
Download config articles