Il y a quelques années, j'ai passé vingt minutes sur une pull request qui modifiait exactement un paquet dans composer.lock. J'ai lu le changelog, parcouru le diff de vendor à la recherche du moindre truc bizarre, et vérifié qui avait les droits de commit sur le dépôt upstream. Pendant cette même revue, mon éditeur a mis à jour onze extensions en arrière-plan. Je n'en ai remarqué aucune, je ne sais toujours pas ce qui a changé, et ce décalage me travaille depuis.

L'outil qui écrit notre code, qui ouvre chaque fichier du dépôt, vendor et .env compris, et qui tourne sous mon propre compte utilisateur est le seul maillon de la chaîne que la plupart des équipes laissent au goût de chacun. Je pense qu'on se trompe. Les extensions d'éditeur ont leur place dans le même panier que les paquets Composer : déclarées par projet, relues quand elles changent, et sous la responsabilité de l'équipe, pas de celui qui les a installées en premier.

Cette année nous a donné raison. Le 18 mai, Nx Console 18.95.0 a été publiée à la fois sur le Visual Studio Marketplace et sur Open VSX avec du code malveillant à l'intérieur. Elle a été retirée rapidement, mais il y a quand même eu une fenêtre. À peu près au même moment, GitHub a révélé que l'appareil d'un employé avait été compromis via une extension VS Code tierce piégée, et que l'affirmation de l'attaquant, qui disait avoir atteint environ 3 800 dépôts internes, correspondait globalement à ses propres constats. Cinq mois plus tard, les détails comptent moins que la façon dont c'est arrivé. Personne n'a installé un outil louche venu d'un inconnu. Un nom auquel les gens faisaient confiance depuis des années a publié une version, et sur desktop, l'hôte d'extensions peut faire tout ce que l'éditeur peut faire : lire et écrire sur le disque, ouvrir des connexions réseau, lancer des processus. Une boîte qui lance composer audit à chaque build de CI peut très bien laisser une porte grande ouverte sur chaque portable.

Le meilleur argument contre moi est solide, et j'ai déjà été de son côté. Les devs choisissent leurs outils, et un éditeur verrouillé rappelle de mauvais souvenirs, comme cette image de poste d'entreprise qui a figé un navigateur antédiluvien pendant des années. Les extensions publient des correctifs en permanence, donc les geler, c'est vivre avec des bugs connus, dont certains sont des failles de sécurité. Et une agence de quatre personnes n'a pas d'équipe plateforme pour faire la moindre curation. J'ai discrètement installé un thème plus joli en douce, contre la politique maison, plus d'une fois, et je le referais.

Mais un lockfile ne gèle rien. composer.lock ne nous a jamais empêchés de mettre à jour. Ce qu'il fait, c'est transformer une mise à jour en changement visible que quelqu'un accepte délibérément. L'équivalent côté éditeur peut être très léger. L'équipe se met d'accord sur un petit socle commun pour le projet, disons ton serveur de langage PHP, l'adaptateur Xdebug et ce qui lance Pint ou php-cs-fixer à l'enregistrement. Tout ce qui sort de ce socle est autorisé, mais c'est sous ta responsabilité. Quand quelque chose change dans le socle commun, ça a droit au même coup d'œil de trente secondes qu'un bump mineur de paquet : celui qui publie est-il toujours celui qu'on croit, et cette version ressemble-t-elle aux précédentes ? Ça ne rattrapera pas tout. Mais ça veut dire que quelqu'un a regardé, ce qui est déjà plus que ce qui se passe aujourd'hui.

On sait faire, et c'est bien ce qui me fait presque rire. Le monde PHP a mis dix ans à faire oublier son époque de scripts copiés depuis des forums directement dans public_html, et Composer plus Packagist ont rendu l'hygiène des dépendances tellement routinière qu'on n'y pense quasiment plus. Les gens de Go ont une base de checksums entre eux et leurs modules, et j'avoue que je suis un peu jaloux. Nos éditeurs n'ont rien de comparable entre nous et un publieur dont le token vient de se faire voler, donc pour l'instant, le seul garde-fou qu'on a, ce sont les habitudes de l'équipe.

Ce que ça coûte vraiment, c'est peut-être une heure par mois de l'attention de quelqu'un, plus une conversation un peu gênante sur qui possède la liste. Je signe tout de suite. « Que chacun fasse attention aux extensions », c'est un conseil dont personne ne peut rien faire. « Qui valide les changements du socle commun de l'éditeur ? », c'est une question que tu peux trancher au stand-up de lundi.

Alors j'aimerais savoir comment ton équipe gère ça. Est-ce que la config de ton éditeur vit à côté de composer.json, comme une décision de projet avec un relecteur désigné, ou est-ce que tu penses que l'éditeur doit rester personnel et que la vraie défense se joue ailleurs, avec des identifiants mieux cloisonnés ou des conteneurs de dev isolés ? Et si tu as essayé d'encadrer les extensions et que tu as fini par laisser tomber, qu'est-ce qui a fait capoter le truc ?