Vor ein paar Jahren habe ich zwanzig Minuten an einem Pull Request gesessen, der genau ein Paket in der composer.lock geändert hat. Ich habe das Changelog gelesen, den Vendor-Diff nach Auffälligkeiten durchsucht und nachgeschaut, wer im Upstream-Repo Commit-Rechte hat. Während genau dieses Reviews hat mein Editor im Hintergrund elf Extensions aktualisiert. Mitbekommen habe ich davon nichts, was sich geändert hat, weiß ich bis heute nicht, und diese Lücke lässt mich seitdem nicht los.

Das Werkzeug, das unseren Code schreibt, jede Datei im Repo öffnet, auch vendor und die .env, und unter meinem eigenen Benutzerkonto läuft, ist bei den meisten Teams der einzige Teil der Toolchain, der reine Geschmackssache bleibt. Ich glaube, da liegen wir falsch. Editor-Extensions gehören in dieselbe Schublade wie Composer-Pakete: pro Projekt festgelegt, geprüft, wenn sie sich ändern, und im Besitz des Teams, nicht dessen, der sie zufällig als Erster installiert hat.

Dieses Jahr hat uns das Argument frei Haus geliefert. Am 18. Mai wurde Nx Console 18.95.0 sowohl im Visual Studio Marketplace als auch auf Open VSX veröffentlicht, mit Schadcode an Bord. Das Release war schnell wieder weg, aber ein Zeitfenster gab es trotzdem. Etwa zur selben Zeit machte GitHub öffentlich, dass das Gerät eines Mitarbeiters über eine manipulierte VS-Code-Extension eines Drittanbieters kompromittiert worden war und dass die Behauptung des Angreifers, an rund 3.800 interne Repositories gekommen zu sein, sich im Großen und Ganzen mit den eigenen Erkenntnissen deckte. Fünf Monate später sind die Details weniger wichtig als die Art, wie es passiert ist. Niemand hat sich ein dubioses Tool von einem Fremden installiert. Ein Name, dem man seit Jahren vertraut hatte, hat ein Release ausgeliefert, und auf dem Desktop kann der Extension Host alles, was auch der Editor kann: auf die Platte lesen und schreiben, Netzwerkverbindungen öffnen, Prozesse starten. Ein Laden, der bei jedem CI-Build composer audit laufen lässt, kann trotzdem auf jedem Laptop ein sperrangelweit offenes Tor haben.

Das beste Gegenargument ist ein gutes, und ich stand selbst schon auf seiner Seite. Entwickler suchen sich ihre Werkzeuge selbst aus, und ein abgeriegelter Editor weckt Erinnerungen an das Firmen-Desktop-Image, das jahrelang einen uralten Browser festgenagelt hat. Extensions liefern ständig Fixes aus, wer sie einfriert, lebt also mit bekannten Bugs, darunter auch Sicherheitslücken. Und eine Agentur mit vier Leuten hat kein Platform-Team, das irgendetwas kuratiert. Ich habe mehr als einmal heimlich und entgegen der Richtlinie ein schöneres Theme installiert, und ich würde es wieder tun.

Aber eine Lockfile friert nichts ein. Die composer.lock hat uns noch nie am Updaten gehindert. Sie macht aus einem Update eine sichtbare Änderung, die jemand bewusst annimmt. Im Editor kann das sehr schlank aussehen. Das Team einigt sich für das Projekt auf ein kurzes gemeinsames Set, etwa deinen PHP-Language-Server, den Xdebug-Adapter und das, was beim Speichern Pint oder php-cs-fixer ausführt. Alles außerhalb dieses Sets ist erlaubt, aber dann liegt es bei dir. Ändert sich etwas im gemeinsamen Set, bekommt es denselben Blick von dreißig Sekunden wie ein kleiner Paket-Bump: Ist der Publisher noch der, für den wir ihn halten, und sieht dieses Release aus wie die vorherigen? Das fängt nicht alles ab. Aber es heißt, dass jemand hingeschaut hat, und das ist mehr als heute.

Wir wissen ja, wie das geht, und das finde ich fast schon komisch. Die PHP-Welt hat ein Jahrzehnt gebraucht, um die Zeit hinter sich zu lassen, in der man Skripte aus Foren direkt nach public_html kopiert hat, und Composer und Packagist haben Abhängigkeitshygiene so selbstverständlich gemacht, dass wir kaum noch darüber nachdenken. Go-Leute haben eine Checksum-Datenbank zwischen sich und ihren Modulen, und darauf bin ich ein bisschen neidisch. Unsere Editoren haben nichts Vergleichbares zwischen uns und einem Publisher, dem gerade sein Token geklaut wurde, also bleiben vorerst nur die Gewohnheiten des Teams als Schutz.

Was das wirklich kostet, ist vielleicht eine Stunde Aufmerksamkeit im Monat von irgendwem, plus ein unangenehmes Gespräch darüber, wem die Liste gehört. Den Tausch nehme ich. „Seid alle vorsichtig mit Extensions“ ist ein Rat, mit dem niemand etwas anfangen kann. „Wer gibt Änderungen am gemeinsamen Editor-Set frei?“ ist eine Frage, die ihr im Standup am Montag klären könnt.

Mich interessiert also, wie dein Team das handhabt. Liegt euer Editor-Setup als Projektentscheidung neben der composer.json, mit einer namentlich zuständigen Person fürs Review, oder findest du, dass der Editor persönlich bleiben sollte und die eigentliche Verteidigung woanders hingehört, etwa zu strengeren Zugangsdaten oder isolierten Dev-Containern? Und falls ihr schon mal versucht habt, Extensions zu regeln, und es wieder aufgegeben habt: Woran ist es gescheitert?