Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

VS Code signe vos commits avec Copilot, même sans Copilot

Par : Korben ✨
6 mai 2026 à 10:16

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...

Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.

Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...

Et puis surtout il y a le bug #313064 qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.

En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.

Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.

Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.

Windows Central a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...

Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118 , le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la PR #313931 , dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.

Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".

Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout a fait légitime.

VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.

En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même jusque dans l'écosystème Apple via une extension Xcode , dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.

Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur VSCodium ou Zed , deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez Codeberg ou Forgejo en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.

À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.

GitHub envahi par de fausses alertes VS Code qui propagent un malware

Par : Korben
30 mars 2026 à 13:42

Des milliers de faux messages imitant des notifications de sécurité Visual Studio Code ont été postés sur GitHub. Le but : rediriger les développeurs vers un site malveillant qui collecte leurs données système. La méthode est franchement vicieuse.

Une campagne massive sur GitHub Discussions

Les chercheurs en sécurité de Socket viennent de mettre le doigt sur une opération d'ampleur. Des centaines, voire des milliers de messages quasi identiques ont été publiés en quelques minutes sur la section Discussions de nombreux dépôts GitHub.

Chaque message reprend le même modèle : un titre alarmiste du type "Vulnérabilité grave Mise à jour immédiate requise", un faux identifiant CVE pour faire sérieux, et un lien vers une prétendue extension VS Code corrigée hébergée sur Google Drive.

Les comptes utilisés sont soit tout neufs, soit quasi inactifs, mais ils se font passer pour des mainteneurs de projets ou des chercheurs en sécurité. Et comme GitHub envoie des notifications par e-mail aux personnes qui suivent un dépôt ou qui sont taguées, les fausses alertes arrivent directement dans la boîte mail des développeurs. Vous pouvez donc vous faire avoir sans même ouvrir GitHub.

Un système de filtrage avant le malware

Bien sûr, le lien Google Drive ne vous amène pas d'un coup vers un fichier infecté. Il déclenche avant une série de redirections qui vous emmènent inlassablement vers un domaine bien foireux, où un script JavaScript va se charger du sale boulot.

Ce script collecte automatiquement le fuseau horaire, la langue, le système d'exploitation, l'identifiant du navigateur et même des indicateurs d'automatisation. Tout est envoyé vers un serveur de commande sans que vous n'ayez à cliquer sur quoi que ce soit.

L'idée derrière ce dispositif, c'est de trier les visiteurs. Les robots et les chercheurs en sécurité sont écartés, et seuls les vrais humains reçoivent la suite de l'attaque. Les chercheurs de Socket n'ont d'ailleurs pas réussi à capturer le malware de deuxième étape, ce qui montre que le filtrage fonctionne plutôt bien.

Ce n'est pas la première fois

GitHub a déjà été ciblé par ce genre de campagne. En mars 2025, une attaque similaire avait touché 12 000 dépôts avec de fausses alertes de sécurité qui poussaient les développeurs à autoriser une application OAuth malveillante.

Cette fois-là, les pirates obtenaient un accès direct aux comptes GitHub des victimes. En juin 2024, c'était via des commentaires et des demandes de fusion bidon que les attaquants redirigeaient vers des pages d'hameçonnage.

Le procédé est malin. Utiliser les notifications GitHub pour donner une apparence officielle à des messages bidons, c'est le genre d'astuce qui marche bien sur des développeurs pressés. 

Bon par contre, un lien Google Drive dans une alerte de sécurité, ça devrait quand même mettre la puce à l'oreille. Si vous recevez ce type de message, vérifiez toujours le CVE sur le site du NVD ou de MITRE avant de cliquer où que ce soit. Et si le lien pointe ailleurs que sur la boutique officielle de VS Code, passez votre chemin.

Source : Bleeping Computer

Un malware invisible se cache dans des caractères Unicode sur GitHub, npm et VS Code

Par : Korben
16 mars 2026 à 14:50

La société Aikido Security a découvert une campagne de malware baptisée Glassworm qui utilise des caractères Unicode invisibles pour dissimuler du code malveillant.

Plus de 150 dépôts GitHub, des paquets npm et des extensions VS Code sont touchés, et le malware utilise la blockchain Solana comme serveur de commande. L'objectif : voler les identifiants de portefeuilles crypto.

Des caractères invisibles qui cachent du code

Le principe est assez fourbe. Les attaquants utilisent des caractères Unicode dits PUA (Private Use Area), qui ne s'affichent pas du tout à l'écran, mais qui contiennent quand même des valeurs exploitables.

Dit plus simplement, chaque caractère invisible correspond à un point de code que le décodeur extrait, reconstruit en payload, puis exécute via eval(). Le code malveillant est là, sous vos yeux, mais vous ne le voyez pas.

Aikido Security a découvert que cette campagne avait eu lieu entre le 3 et le 9 mars derniers. Plus de 150 dépôts GitHub ont été compromis, mais aussi des paquets npm comme @aifabrix/miso-client et @iflow-mcp/watercrawl-watercrawl-mcp.

Si on regarde du côté de VS Code, l'extension quartz-markdown-editor et 72 extensions sur Open VSX ont été touchées. Les attaquants ont aussi utilisé des LLM pour générer des commits de couverture parfaitement crédibles, et passer ainsi sous les radars des reviewers.

La blockchain Solana impliquée

Ce qui rend Glassworm encore plus fourbe, c'est son infrastructure. Au lieu d'utiliser un serveur classique facile à bloquer, le malware récupère ses instructions de commande sur la blockchain Solana. Ce qui veut dire qu'il n'y a pas de serveur central à couper : les instructions sont inscrites dans la blockchain, accessibles à tous et quasi impossibles à supprimer.

L'objectif final est le vol de données liées aux portefeuilles crypto. Le malware cible 49 extensions de navigateur, dont MetaMask, Coinbase Wallet et Phantom. Il récupère les identifiants stockés localement et les exfiltre vers les serveurs des attaquants.

Côté attaquants, c'est du beau travail. Cacher du code dans des caractères que personne ne voit, utiliser une blockchain comme canal de commande et se servir d'IA pour maquiller les commits, c'est bien ficelé.

Le problème, c'est que ça expose un angle mort assez gênant dans la confiance qu'on accorde à l'open source : on installe des paquets et des extensions sans forcément lire chaque ligne de code, et quand le code malveillant est carrément invisible, ça devient compliqué à détecter.

Sources : Aikido.dev , Socket.dev

Dotenv Mask Editor - Fini les clés API à l'air libre

Par : Korben
10 mars 2026 à 09:35

Et si vos fichiers .env se transformaient en un joli tableau avec des astérisques partout afin d'assurer la confidentialité de vos clés API et autres crédentials ? Hé bien c'est exactement ce que propose Dotenv Mask Editor , une extension VS Code qui remplace carrément l'éditeur texte par une grille.

Du coup, vos clés API, tokens AWS, mots de passe PostgreSQL et autres STRIPE_SECRET_KEY s'affichent sous forme de ****** et vous pouvez bosser dessus même si quelqu'un mate par-dessus votre épaule.

En gros, dès que vous ouvrez un fichier .env (ou .env.local, .env.production... bref, tout ce qui matche le pattern), l'extension vous présente vos variables dans un tableau à deux colonnes. Les clés à gauche, les valeurs masquées à droite. Pour modifier une valeur, hop, vous cliquez dessus et elle se dévoile le temps de l'édition. Vous cliquez ailleurs, c'est re-masqué. Pas de sauvegarde manuelle à faire, ça se fait tout seul.

Le masquage se déclenche à partir de 6 caractères (en dessous, c'est probablement pas un secret... genre PORT=3000 ou DEBUG=true, on s'en fiche). Et le truc cool, c'est que tout tourne en local sur votre machine.

Si vous vous dites "mais attends, y'a pas déjà Camouflage pour ça ?"... oui et non. Camouflage masque vos secrets avec un overlay pendant les démos et le partage d'écran, mais vous continuez à éditer dans l'éditeur texte classique. Dotenv Mask Editor, lui, change complètement l'interface, c'est un éditeur de tableau dédié aux variables d'environnement. Deux approches différentes du coup, et rien ne vous empêche d'utiliser les deux.

L'extension est sous licence MIT, fonctionne sur toutes les plateformes (Windows, Linux, macOS, même VS Code Web) et vous pouvez ajouter des patterns de fichiers personnalisés dans vos settings.json.

D'ailleurs, si vous voulez l'installer, c'est du classique : Ctrl+Shift+X dans VS Code (Cmd+Shift+X sur Mac), vous tapez "dotenv mask" et voilà.

Avec ça, vos secrets restent secrets mais faut quand même pas oublier de mettre votre .env dans le .gitignore hein. ^^

MkEditor - L'éditeur Markdown que personne n'attendait

Par : Korben
12 août 2025 à 14:16

Moi, j’adore quand quelqu’un fabrique un truc juste parce qu’il en a envie, sans business plan, sans pitch deck, sans lever de fonds. Juste un dev, son clavier, et l’envie de créer.

Et bien c’est exactement ce qui s’est passé avec MkEditor, et ça fait du bien !

Le créateur de MkEditor (qui se décrit lui-même comme “un peu timide pour partager ses créations”) a passé plusieurs années à maintenir cet éditeur Markdown qui respecte les specs CommonMark.

Pourquoi ?

Et bien pas pour concurrencer Obsidian ou Typora. Pas pour devenir la prochaine licorne de la tech. Non, non, juste parce qu’il voulait comprendre comment VSCode fonctionnait en détail. Et ce qu’il nous a pondu, c’est un éditeur qui utilise Monaco Editor de Microsoft, le même moteur qui fait tourner VSCode.

Alors oui, on va me dire “mais Korben, il existe déjà 50 éditeurs Markdown”. C’est vrai et ces éditeurs ont su se rendre incontournables pour les développeurs et les équipes. Obsidian cartonne avec son graph view, Typora fait toujours rêver avec son rendu en temps réel. Mais MkEditor a quelque chose de différent : Il ne cherche pas à révolutionner quoi que ce soit. Il fait juste très bien ce qu’il fait.

L’outil embarque des fonctionnalités plutôt sympas. D’abord, vous avez un split screen redimensionnable avec synchronisation du scroll entre l’éditeur et la preview. Ensuite, des raccourcis clavier personnalisables pour formater votre texte ou insérer des blocs de code. Et il y a même de l’autocomplétion pour les langages dans les code blocks, exactement comme dans VSCode.

Ce qui est bien pensé aussi, c’est l’export HTML. Vous pouvez comme ça générer du HTML brut ou une version stylée avec Bootstrap et FontAwesome directement injectés dans le <head>. Pratique quand vous voulez partager un document qui a de la gueule sans vous prendre la tête avec le CSS. Les paramètres sont configurables soit via l’interface, soit directement dans un fichier settings.json pour les puristes du terminal.

Le truc cool aussi, c’est qu’il y a la palette de commandes de VSCode. Vous tapez Ctrl+Shift+P (ou Cmd+Shift+P sur Mac) et boom, vous avez accès à toutes les commandes. Pour ceux qui vivent dans VSCode, c’est comme retrouver ses pantoufles.

Et si vous ne voulez pas installer l’application desktop (disponible en Electron pour Windows, Linux et macOS), vous pouvez tester directement la version web en cliquant ici. Pas de compte à créer, pas de données à fournir, vous arrivez et vous écrivez. C’est chouette non, à une époque où chaque app veut votre mail, votre 06 et votre groupe sanguin.

Le développeur l’avoue lui-même dans son post… il a créé MkEditor juste parce qu’il en avait envie, sans cas d’usage particulier, juste pour le plaisir de construire quelque chose. C’est cette philosophie qui résume tout ce que j’aime dans l’open source.

Le projet est donc sur GitHub si vous voulez contribuer ou juste jeter un œil au code. Le dev accepte les feedbacks et les rapports de bugs, toujours avec cette modestie qui caractérise les vrais artisans du code.

Alors non, MkEditor ne va pas détrôner les géants du Markdown et il ne va pas lever 10 millions (enfin, quoique, on ne sait jamais dans la vie…). Il n’aura peut-être même pas sa propre conférence annuelle, mais il existe, il fonctionne bien, et il est gratuit.

❌
❌