#27 Sicherheit in der Dependency Hölle

Was haben die JavaScript Pakete left-pad, color, faker und cross-env gemeinsam? Alle waren in npm Package Sicherheits-Incidents involviert.

Wenn man sich die Anzahl von Javascript Abhängigkeiten bei Mittelgroßen Projekten ansieht, ist eine dreistellige Anzahl an JavaScript Paketen nicht unüblich. Das liegt primär an der überschaubaren Größe der Pakete und somit der Funktionalität. Alles nur, um Pakete verwaltbarer zu halten. Doch dieser Umstand macht das JavaScript-Ecosystem so attraktiv für Angreifer oder kann zu extremen Seiteneffekten führen. In dieser Episode sprechen wir drei npm Package Incidents durch, was es damit aufsich hatte, welche Attack-Möglichkeiten es noch gibt und wie man sich als Software Entwickler dagegen schützen kann.

Bonus: Was Bademeister, Blubberwasser und eine ASCII-Repräsentation von Uncle Sam und der amerikanischen Flagge mit JavaScript zu tun haben.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Weitere nicht behandelte Incidents

ua-parser.js (malicious code / account hijack): https://github.com/advisories/GHSA-pjwm-rvh2-c87w
coa (malicious code): https://github.com/advisories/GHSA-73qr-pfmq-6rp8
rc (malicious code): https://github.com/advisories/GHSA-g2q5-5433-rhrf
purescript (malicious code by dependencies): https://harry.garrood.me/blog/malicious-code-in-purescript-npm-installer/
event-stream (new maintainer injected code to steal bitcoins / social engineering): https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
getcookies (backdoor): https://blog.npmjs.org/post/173526807575/reported-malicious-module-getcookies.html

Sprungmarken

(00:00:00) Intro

(00:00:35) Intro: 10.000 Downloads und Die Bademeister

(00:01:42) Wie viele Firmen setzen (bewusst) Open Source ein?

(00:04:09) Wie viele Firmen unterstützen Open Source finanziell?

(00:06:22) Open Source Funding via Media Tech Lab

(00:08:11) Das Management von Software-Dependencies anhand des JavaScript-Ecosystems via npm

(00:08:59) Warum JavaScript als Beispiel genutzt wird und die Theorie warum JavaScript Pakete so klein sind und viele Abhängigkeiten haben

(00:15:06) npm Package Incident: Das Paket "left-pad" wurde aus der npm Registry entfernt (unpublished)

(00:23:06) npm Package Incident: Die Pakete "color" und "faker" geben Textmüll auf der Konsole aus

(00:27:29) npm Package Incident: Das Paket "cross-env" und der typosquatting-Angriff mit "crossenv"

(00:33:01) Weitere Angriffs-Vektoren in Bezug auf Software Dependencies: Böswilliger Maintainer, Schadcode in Sub-Dependency, Account-Übernahme und die falsche Package Registry

(00:40:23) Ein Lösungsweg: npm package scopes

(00:42:02) Weitere Lösungswege: Schadcode und frühere Fraud-Detection auf Plattform-Seite, die Überwachung von direkten Dependencies und Version-Pinning

(00:47:40) Dependabot: Versionen von Dependencies automatisch updaten und auf neue Dependencies achten

(00:53:44) Der gesunde Streit: Zanken und Bierchen

(00:54:17) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:00 - 00:00:03)

Willkommen in der Dependency Hell.

Wolfi Gassler (00:00:03 - 00:00:40)

Keine Angst, wir sind's vom Engineering Kiosk. Und in dieser Episode beleuchten wir eine sicherheitsrelevante Schattenseite des Dependency Managements. Vermutlich kennt jeder Left Bad. Aber wie wurde denn Shardcode in NPM-Pakete überhaupt eingeschleust? Welche Motive stecken dahinter und wie können wir uns als Softwareentwickler und Firmen gegen solche Vorfälle eigentlich schützen? Aber bevor wir damit anfangen, widmen wir uns einem anderen sicherheitsrelevanten Thema, den Gefahren von Blubberwasser und Andis Vorliebe für Bademeister. Andi, gratuliere zu 10.000 Downloads. Woohoo!

Andy Grunwald (00:00:40 - 00:00:41)

Hast du Sekt aufgemacht?

Wolfi Gassler (00:00:41 - 00:00:43)

Ja, da bekomme ich immer Schädelweh.

Andy Grunwald (00:00:43 - 00:00:54)

Kopfschmerzen heißt das. Aber du weißt schon, kennst du den Film Die Bademeister? Nö. Das ist so ein Ruhrpott-Film, verstehst du?

Wolfi Gassler (00:00:54 - 00:00:55)

Ja, eben, warum kenn ich den nicht?

Andy Grunwald (00:00:55 - 00:01:17)

Da wird jemand, der unter Tage arbeitet, ich glaube aus Bochum oder Essen oder sowas, der wird dann Bademeister und mit seinen Kumpels wird er dann Bademeister auf Sylt. Du kannst dir ja vorstellen, dass es da einen kleinen Kulturclash gibt, ja. Ist so ähnlich wie die Punks gerade auf Sylt mit dem 9-Euro-Ticket. Auf jeden Fall geht es dann natürlich auch um Sekt und Champagner in irgendeiner Art und Weise, ja. Und da kommt der populäre Spruch her, Blubberwasser verdirbt den Charakter.

Wolfi Gassler (00:01:18 - 00:01:20)

Ah, den kenn ich natürlich.

Andy Grunwald (00:01:20 - 00:01:34)

Ich glaube, der wurde durch diesen Film geprägt. Auf jeden Fall ist es eins meiner Mantras. Zumindest, damit du die Pommes-Currywurst, die Manta-Platte, all diese Kulturen nicht verlierst. Finger weg von Blubberwasser.

Wolfi Gassler (00:01:34 - 00:01:59)

Okay, also in dem Fall stoßen wir einfach mit einem guten Kaffee an. Nachdem es noch fast in der Nacht ist, bleiben wir eher beim Kaffee und gehen aufs Bier üben am Abend oder so. Aber ich habe eine andere Frage an dich und zwar habe ich im Vorfeld für die Recherche von dieser Episode ein paar Infos rausgesucht und ich würde gerne von dir wissen, was du glaubst, wie viele Firmen Open Source einsetzen, prozentuell.

Andy Grunwald (00:01:59 - 00:02:02)

Und da sprechen wir ja wirklich über alle Industrien hinweg, richtig?

Wolfi Gassler (00:02:02 - 00:02:09)

Das ist eine gute Frage, ich sag einfach mal ja. Das ist bei diesen Studien sowieso immer alles sehr schwierig, aber nehmen wir mal an, ja.

Andy Grunwald (00:02:09 - 00:03:04)

Dann würde ich sagen 99 Prozent, 100 Prozent oder ähnliches, weil wenn ich an OpenSSL denke, an OpenSSH, an CURL, das ist das Software, das weltweit deployed wird. Also ich meine, ich kann ja noch nicht mehr als mehr meine Hose waschen. weil auf meiner Waschmaschine Curl läuft, also von daher ohne Open Source kriege ich nur mal saubere Wäsche. Von daher kann ich mir auch im Firmenumfeld schwer vorstellen, dass Leute da keine Open Source Software anwenden. Es kann natürlich sein, dass wenn du jetzt auf eine Studie gehst, die sagt, okay, wie viele Firmen setzen bewusst und nicht als Unter-Unter-Dependency von ihrem iOS oder ähnliches Open Source ein? Wie viele setzen wirklich bewusst Open Source ein? Da würde ich mal schätzen, liegt der Prozentsatz nicht so hoch bei 99 oder 100 Prozent, weil ich denke, die meisten Leute verwenden es trotzdem, aber die Leute, die bei der Studie beantwortet haben, haben dann keinen Schimmer, was die Leute unten drunter machen. Deswegen gehe ich mal stark davon aus, dass die Studie irgendwas um die 65 bis 70 Prozent sagt.

Wolfi Gassler (00:03:05 - 00:03:23)

Sehr gut, zwei Drittel, sogar mehrere Studien gehen eigentlich ungefähr immer auf diese zwei Drittel. Aber wie du richtig sagst, es ist wahrscheinlich die, die wissentlich Open Source einsetzen, weil ich glaube auch, wenn du heutzutage Windows einsetzt, ich vermute, dass da auch Open Source Teile irgendwo drin sind, oder? Oder ist Microsoft komplett frei von Open Source?

Andy Grunwald (00:03:24 - 00:03:38)

Naja, erstens .NET ist ja schon mal Open Source, ne? Fangen wir erst mal da an. Die zweite Geschichte, dass Windows, natürlich moderne Windows-Systeme, auch eine Linux-Subshell haben und spätestens da kommst du dann nicht um Sachen wie den Support von Bash und Corum.

Wolfi Gassler (00:03:38 - 00:03:56)

Okay, aber die brauche ich jetzt als Firma selten. Also das ist nur, wenn ich es wirklich verwende und mir bewusst bin, dass ich Linux verwende. Aber jetzt in einem klassischen Windows-Core, wenn ich den hochfahre, verwende ich da irgendwo Open Source, der nicht von Microsoft entwickelt wurde. Weißt du das zufällig? Ist Curl zum Beispiel in Windows irgendwo drin?

Andy Grunwald (00:03:56 - 00:04:00)

100% ist Curl bei Windows drin. Also ich lehne mich jetzt mal weit aus dem Fenster.

Wolfi Gassler (00:04:00 - 00:04:23)

Falls es jemand weiß, bitte Informationen, twittet uns das, ob Curl irgendwo im Windows-Kern drin ist. Und dann noch ein anderes sehr interessantes Fact in dieser Studie, die ich da gefunden habe, die ist übrigens von 2022 und nicht nur über Deutschland. Wie viele Firmen denn Open Source finanziell unterstützen? Was denkst du?

Andy Grunwald (00:04:23 - 00:04:33)

Da würde ich die prozentuale Zahl mal umdrehen und würde sagen auf einen niedrigeren einstelligen Prozentsatz. Ich wäre überrascht, wenn es fünf Prozent sind. Ich würde eher sagen niedriger.

Wolfi Gassler (00:04:33 - 00:05:32)

Das Problem ist, glaube ich, da, dass eben da random irgendwelche Leute angeschrieben worden sind, beziehungsweise gefragt worden sind. Und da sind halt Rückmeldungen von überall gekommen, von der ganzen Welt. Und ich vermute halt, dass die Leute sich eher rückmelden, die vielleicht auch Open Source finanziell unterstützen oder da Interesse haben, und die dann eher erreicht worden sind mit dieser Studie. Also in dieser Studie sagen 79 Prozent, dass mindestens ein Open-Source-Tool oder eine Open-Source-Organisation finanziell unterstützt wird. In der Realität kann ich mir das aber auch ehrlich gesagt schwer vorstellen, wie du richtig sagst, wenn man das auf alle Firmen umbricht. Ich glaube, das muss wesentlich weniger sein. Also das sind sehr motivierte Leute, die da glaube ich geantwortet haben, weil Wir haben ja selber auch da schon einiges gemacht in dem Space oder probiert mit Finanzierungsmodellen und haben da mit vielen Leuten gesprochen und es ist so schwierig im Open Source Bereich irgendwas zu bekommen und wenn es nur irgendwie 5 Dollar sind als kleine Donation, ist extrem schwierig.

Andy Grunwald (00:05:33 - 00:06:13)

Ich glaube die Open Source Community hätte kein Problem damit, wenn wirklich 79% aller Firmen, die Open Source explizit einsetzen, mindestens ein Open Source Projekt unterstützen. Es kann natürlich auch sein, dass die alle nur React unterstützen und somit React natürlich eine sechsstellige Anzahl an Geld hat. Alles schön und gut. Und somit nichts bei den Sub-Sub-Sub-Sub-Sub-Dependencies ankommt. Das kann natürlich auch sein. Aber in der Regel sind diese Megaprojekte natürlich schon gebackt von Facebook, von Google und Microsoft von den Großen. Auf jeden Fall, ich denke zum Thema Open Source Sponsoring im Allgemeinen, was daran so eigentlich so kompliziert ist und was die Problematik in der Industrie eigentlich sind. Ich glaube, da können wir in Zukunft auch mal eine spezialisierte Podcast-Episode dazu machen.

Wolfi Gassler (00:06:13 - 00:06:24)

Da haben wir ja auch schon viel Zeit investiert und teilweise auch aufgegeben müssen wir sagen, weil es eben extrem schwierig ist. By the way, wir haben gestern auch gerade mit einer Firma telefoniert, beziehungsweise eigentlich.

Andy Grunwald (00:06:24 - 00:06:27)

Ist es so eine staatliche Organisation vielleicht sogar.

Wolfi Gassler (00:06:27 - 00:08:26)

Genau, also eine staatliche Organisation oder zumindest gefördert und die fördern Open Source Entwicklung und das ist eigentlich ein super interessantes Modell. Wir haben uns das auch erklären lassen, die vergeben Stipendien an Open Source Entwickler und man kann da ein Projekt einreichen und bekommt dann für sechs Monate 50.000 Euro bezahlt für ein Open Source Projekt, was man entwickeln kann, solange es eben größeren Umkreis von Medienproduktion ist, also das heißt von Fernsehen, Radio, Podcasts, Journalismus, auch die ganze technische Seite von der Erstellung von Content, kann auch Content Creator sein, also es ist wirklich extrem breit gefasst, kann viel sein und die vergeben einige Stipendien pro Jahr, was sie uns aber auch gestern gesagt haben, der aktuelle Einsenderschluss ist am 15. glaube ich war das, das heißt, wenn ihr jetzt gerade die Episode hört, habt ihr wahrscheinlich noch paar Tage Zeit, aber es ist super einfach, es ist ein kurzes Formular, das auszufüllen ist. Also da braucht man nicht irgendwie ein 20-seitiges Dokument oder sowas stellen, das ist relativ einfach. Verlinken wir natürlich auch gerne, nennt sich Media Tech Lab. Also wer Interesse hat, mal da full-time dann natürlich wirklich sechs Monate an einem Open-Source-Projekt zu arbeiten und sich da finanzieren zu lassen, schaut einfach mal rein, wir verlinken das. Weil es ist sonst wirklich extrem schwierig mit Open Source Geld zu machen oder halt einfach davon zu leben womöglich. Auch wenn natürlich viele von ihrer Firma bezahlt werden, wenn sie Open Source entwickeln, aber ganz ganz viele Open Source Projekte werden einfach aus der privaten Tasche finanziert in der Freizeit. Aber wir wollen heute gar nicht über dieses Finanzierungsproblem sprechen, sondern über ein sehr verwandtes Problem, was auch indirekt mit dem Finanzierungsproblem von Open Source zusammenhängt. Und zwar geht es um Dependencies auf Open Source Libraries, die wir ja alle in irgendeiner Form haben und wie wir damit umgehen, weil die einfach auch ein großes Security-Risiko sein können.

Andy Grunwald (00:08:26 - 00:08:43)

Mit Dependencies meinen wir jetzt nicht, was Windows oder Linux drunter einbindet, sondern eher um wirklich explizierte Dependencies, die ihr in euren Softwareprojekten mit einbindet. In unserer heutigen Episode stürzen wir uns da auf unsere Lieblingssprache JavaScript und primär auf das NPM-Ekosystem.

Wolfi Gassler (00:08:43 - 00:08:50)

Moment, seit wann? Normal sagst du immer, JavaScript ist keine Sprache. Jetzt ist es schon deine Lieblingssprache. Du entwickelst dich ja schnell weiter.

Andy Grunwald (00:08:50 - 00:08:51)

Ich muss mir ja hier auch Freunde machen.

Wolfi Gassler (00:08:52 - 00:08:54)

Warum gerade JavaScript?

Andy Grunwald (00:08:54 - 00:10:02)

All das, was wir hier besprechen, lässt sich natürlich auch auf andere Sprachen übertragen. PHP mit Composer, Python mit Pip oder auch auf klassische Git-Repositories wie zum Beispiel bei Go. Wir nutzen aber mal JavaScript und das NPM-Ekosystem einfach als exemplarisches Beispiel, weil auf der einen Seite und das ganze Ecosystem sehr viele recht gute und recht plakative Beispiele aus den letzten Jahren gibt, was da so schief gegangen ist. Thema LeftPad, Thema Color und Faker-Pakete. Vielleicht klingelt da was bei euch. Da besprechen wir gleich mal ein bisschen mehr zu. Aber primär darum, warum JavaScript, ist relativ einfach. Viele JavaScript-Projekte haben eine sehr, sehr, sehr große Anzahl an Subdependencies. Und die Anzahl der Subdependencies ist im Vergleich zu anderen Programmiersprachen deutlich höher. Also ich kenne zum Beispiel kein PHP-Projekt, was über 100 Dependencies hat. Bei JavaScript ist das, glaube ich, mal schon eher ein deutlich kleineres Projekt, wenn man nur 100 Subdependencies hat.

Wolfi Gassler (00:10:02 - 00:10:39)

Wenn wir schon bei der Fragestunde sind heute, Andi, ihr habt ja damals vor langer Zeit auch gemeinsam mit dir, wo wir eben probiert haben, dieses Open-Source-Finanzierungsproblem zu lösen, so einen Analyzer geschrieben, der die Dependencies analysiert, rekursiv. Ihr habt ja gerade mal ein Testprojekt von mir reingesteckt, also Package.json. Und zwar wird da eigentlich nur Nuxt und Axios verwendet für sowas wie Curl im Prinzip, dass man HTTP-Requests gewrapped hat. Was glaubst du, nur Nuxt und Axios, wie viele Dependencies benötigt dieses Projekt?

Andy Grunwald (00:10:39 - 00:10:41)

Aus dem Bauch heraus würde ich sagen 650.

Wolfi Gassler (00:10:41 - 00:11:21)

Du bist ziemlich knapp dran. Es sind 780 Runtime Dependencies und 521 Dev Dependencies. Also zwei eingebundene Pakete im Package.json bedeutet im Hintergrund werden 780 Runtime Dependencies geladen. Also rekursiv natürlich, weil jedes andere Projekt hat wieder andere Abhängigkeiten und so kommt man auf diese 780 Dependencies. Und wenn man jetzt diese 780 Dependencies selbst überwachen sollte, was denn da für Code reinkommt, dann kann man sich vorstellen, dass das eher auf der schwierigeren Seite ist.

Andy Grunwald (00:11:21 - 00:13:35)

Und es ist natürlich immer ein Running Joke, wie viele Subdependencies ein JavaScript-Projekt hat. Alle Leute, die JavaScript schreiben, nehmen das einfach so hin. Alle Leute, die nicht JavaScript schreiben, lachen immer darüber, beziehungsweise fluchen immer, wenn sie ein NPM-Install machen müssen. Aber habt ihr euch eigentlich schon mal gefragt, warum es denn im JavaScript-Ökosystem so ist, dass alle Pakete so klein sind und dann als logische Schlussfolgerung die Pakete oder die Applikationen immer mehr Dependencies haben? Und da habe ich in letzter Zeit eine schöne Theorie von Nadia Ekbal gelesen. Nadia Ekbal ist die Autorin des Buchs Working in Public, The Making and Maintainance of Open Source Software. Und zwar hat die Dame sich damit auseinandergesetzt und hat analysiert, wie Open Source-Communities arbeiten. Und in dem Intro von dem Buch wird unter anderem gesagt, ja, Open Source hat das generelle Maintainance-Problem. Es sind die meisten Open Source Projekte immer nur von einer Person maximal zwei maintained und das primär in der Freizeit. Das führt dazu, dass immer mehr Features und Co. natürlich ihren Weg in die Codebase finden und Pull Requests auch angenommen werden und Pull-Request bedeutet eigentlich, der Wolfgang macht ein Pull-Request an mein Open-Source-Projekt und überführt seinen Code in meine Maintainance und ich als Projekt-Maintainer muss das dann maintainen. Das JavaScript-Ecosystem hat dann somit festgestellt, hey, pass mal auf, umso größer meine Codebase wird, Umso schlechter kann dieses Projekt maintained werden, weil wie viel Lines of Code kann ein Single Maintainer in der Freizeit denn maintain? Deswegen ist das JavaScript-Ekosystem meist dazu hingegangen und hat kleinere Funktionen gemacht und die Lines of Code wirklich pro Paket reduziert, um es deutlich maintainbarer zu machen. Das ist so die Theorie von Nadia Ekbal. Meines Erachtens nach klingt diese recht logisch, besonders wenn man dann jetzt so Sachen sieht, wie zum Beispiel LeftPad. LeftPad, ihr erinnert euch alle, ist ein kleines Paket mit stolzen 11 Zeilen Code, was eigentlich gesagt hat, okay, du hast einen String und lässt den LeftPadden mit einem Charakter deiner Wahl, was meist dann zum Beispiel ein Leerzeichen ist, um zum Beispiel einen Text in einer Tabelle rechts oder ähnliches auszurichten.

Wolfi Gassler (00:13:36 - 00:13:40)

Also eigentlich ist es eine Antwort auf eine Stackoverflow-Frage.

Andy Grunwald (00:13:41 - 00:13:44)

Ist das jetzt ernst? Ist das Paket aus einer Antwort auf eine Stackoverflow-Frage entstanden?

Wolfi Gassler (00:13:45 - 00:13:59)

Nein, aber es hat die gleiche Qualität wie eine Stackoverflow-Antwort, oder? Ich gehe auf Stackoverflow, suche mir irgendwie, wie kann ich LeftPad schnell implementieren und kopiere dann diese Vorschleife oder so. Also es entspricht ungefähr einer Antwort auf Stackoverflow.

Andy Grunwald (00:13:59 - 00:15:12)

Könnte eine klassische Stackoverflow-Antwort sein, in der Tat. Auf jeden Fall ist das so die Theorie, dass sich das NPM-Ekosystem halt eher auf kleine Pakete fokussiert hat, auf ein reduziertes Feature-Set, so dass die einzelnen Pakete auch von einzelnen Personen maintainbar sind und maintainbar bleiben. Die Theorie erschließt sich mir, finde ich recht logisch. Hat natürlich dann aber auch zur negativen Folge, dass jedes Paket eine sehr große Anzahl an Abhängigkeiten benötigt, die es dann für euch natürlich sehr hart macht, alle Dependencies zu auditen, weil ihr wisst ja gar nicht wirklich, was ihr in eurem Projekt habt. Und weil diese Audits so hart sind, ist das NPM-Ekosystem in irgendeiner Art und Weise prädestiniert für Angreifer, beziehungsweise für Inzidenz. Und in den nächsten paar Minuten wollen wir eigentlich mal über verschiedene Arten von diesen Inzidenz bei NPM-Packages sprechen. Wir haben uns mal drei rausgesucht, drei verschiedene Arten von Inzidenz und die wollen wir einmal Durchleuchten. Wolfgang, wenn wir über NPM-Package-Inzidenz sprechen, was ist deine erste Antwort? Was kommt dir in den Sinn?

Wolfi Gassler (00:15:12 - 00:15:41)

Ja, natürlich wieder Leftpad. Darum ist ja Leftpad wahrscheinlich das bekannteste Paket schlechthin, weil es hat elf Zeilen Code und ich weiß nicht, wie viele Artikel über diese elf Zeilen Code schon geschrieben worden sind oder wie viele Leute darüber gesprochen haben, so wie wir es jetzt machen. Und bekannt ist es natürlich damals geworden durch einen Inzidenz, weil Dieses Left Bad Paket, keine Ahnung mehr, in wieviel Code Basis es drin war, aber Millionen schätze ich mal. Und irgendwann ist es dann verschwunden.

Andy Grunwald (00:15:41 - 00:17:37)

Das was du wiedergegeben hast, das wird den meisten auch so im Kopf sein. Aber gehen wir mal in den Fall Left Bad und was denn da wirklich passiert ist. Das ist nämlich ganz interessant. Und zwar hat sich die ganze Sache im März 2016 zugetragen. Ist also schon ein paar Jährchen her. In meinem Kopf, als ich es recherchiert habe, hatte ich irgendwie das Gefühl, das war letztes Jahr oder ähnliches. Naja, gut, vielleicht werden wir einfach nur älter. Auf jeden Fall, was ist passiert? Und zwar gibt es einen Entwickler, der nennt sich Azer Kotschulu. Azer Kotschulu ist der Autor von ungefähr 270 NPM-Packages. Eins dieser NPM-Pakete hatte den Namen KIK. K-I-K. Also eigentlich wie dieser deutsche Discounter. Der Name Kik war also in der NPM Registry auf Asia Cucullu registriert. Und irgendwann hat er eine E-Mail bekommen von einer Firma, die heißt ebenfalls Kik. Und zwar ist das Kik.com. Kik.com ist nicht der deutsche Billig-Discounter. Kik.com ist eine Messaging-App für iOS und Android. Und was diese Firma vorhatte, war ein eigenes NPM-Package zu publishen. Somit haben sie dem Autor eine E-Mail geschrieben, hey, Wir sind diese Messaging-Firma und wir würden gerne ein eigenes NPM-Package publischen. Können wir den Namen haben? Können wir den Namen Kik auf der NPM-Registry haben? Der originale Autor sagt, ach du, ich baue ein Open-Source-Paket mit demselben Namen, somit gebe ich den Namen nicht ab. Ein bisschen hin und her, dann sagt der Mensch von dieser Firma, hey kann ich den Namen vielleicht abkaufen? Dann sagt der Autor, ja für 30.000 Dollar und fuck you. Die Firma hat sich danach an die Firma hinter MPM gewendet und hat gesagt, hey pass mal auf, wir haben hier Kick, das ist hier eine Trademark, ein registriertes Trademark und ich habe wirklich versucht mit dem originalen Autor eine gute Lösung zu finden, hat aber irgendwie nicht funktioniert und Da sind auch ein paar Schimpfwörter geflogen. Achso, lustigerweise, der ganze E-Mail-Verkehr ist öffentlich. Der ist im Internet gepublished worden.

Wolfi Gassler (00:17:38 - 00:17:39)

Linken wir natürlich.

Andy Grunwald (00:17:39 - 00:17:52)

Was hat NPM gemacht? Riesenfehler. NPM hat den Namen Kik von dem originalen Open-Source-Autor auf diese Mobiling-Messaging-Firma übertragen. Böser Fehler.

Wolfi Gassler (00:17:52 - 00:17:59)

Großer Fehler. Weißt du, ob das rechtlich vielleicht nicht auch so ist, dass man das muss, wenn es ein Trademark ist? Keine Ahnung.

Andy Grunwald (00:17:59 - 00:18:28)

Sehr gute Frage. Mich würde es aber irgendwie wundern, weil im Endeffekt ist das nur ein Name auf irgendeiner Plattform. Das bedeutet, nur weil ich ein Trademark auf Andi Grumwald habe, heißt das ja nicht, dass ich den Twitter-Namen, dass ich recht auf den Twitter-Namen habe, oder? Ich weiß, dass es bei Domains so ist, weil die Total-Tankstelle mal rechtlichen Streit gewonnen hat für total.com, glaube ich. Aber ob das dann jetzt bei Twitter-Namen oder NPM-Paketen so ist, weiß ich jetzt auch nicht. Aber ich glaube, das ist auch sehr, sehr schwierig zu sagen, weil die Rechtsprechung je nach Land anders ist, oder?

Wolfi Gassler (00:18:29 - 00:18:43)

Ja, wir sind auch keine Patentanwälte oder Namensanwälte, besser gesagt. Aber es könnte durchaus sein, dass das, wenn man da Druckhaus übt, dass das womöglich nötig ist. Aber okay, im Nachhinein hat sich auf jeden Fall herausgestellt, dass es keine so gute Idee war.

Andy Grunwald (00:18:44 - 00:19:55)

Auf jeden Fall hat dann die Firma hinter NPM den Namen Kick auf die Mobile Messaging Firma übertragen. Das hat den originalen Open Source Autor so dermaßen angepisst und hat gesagt, hör mal, pass mal auf NPM, das hab ich nicht von euch erwartet, weil der NPM-CTO und dieser Aser, dieser Open Source Autor, die kannten sich persönlich, weil die leben beide in Kalifornien. Und dann sagt der, auch wisst ihr was, fickt euch alle, ich zieh all meine 270 Pakete von NPM runter, weil so ne Scheiße lass ich nicht mit mir machen. Und eins dieser 270 Pakete war LeftPad. Das bedeutet, der originale Open-Source-Autor ist hingegangen, hat 270 Pakete aus der NPM Registry unfublished, das ist der offizielle Term, um etwas wieder runterzunehmen. Und das hat dazu geführt, dass von jetzt auf gleich Pakete wie React, Node oder auch der Code Transpiler Babel einfach mal gefailt sind, weil die Dependency LeftPad als Sub-Sub-Sub-Sub-Dependency hat. weil einfach nur ein Entwickler in der Public NPM Registry all seine Pakete geunpublished hat, weil NPM die Namensrechte von einem völlig anderen Paket, nämlich von dem Kik-Paket, an eine Firma übertragen hat.

Wolfi Gassler (00:19:56 - 00:20:32)

Und üblicherweise ist es ja so, dass das jetzt kein Binary ist, wie in anderen Sprachen teilweise oder in anderen Ecosystemen, wo wenn ich zum Beispiel React einbinde, dass das eine Binary ist, die schon alle Abhängigkeiten drin hat, sondern wenn ich mir jetzt React installiere in meinem Projekt, dann werden alle nötigen Abhängigkeiten natürlich zusätzlich gefetscht und wenn das LeftBed nicht verfügbar ist, baut mein gesamtes Projekt gar nicht mehr. Also alle, die probiert haben, irgendwie React zu verwenden, hatten in dem Fall keine Chance mehr, weil LeftBed gefehlt hat. Seht ihr das richtig?

Andy Grunwald (00:20:32 - 00:21:36)

Das ist korrekt. Natürlich hat das ganze Internet da aufgeschrien und was ist da los und der originale Open Source Autor hat dann natürlich auch eine Stellungnahme zugegeben und hat gesagt, pass mal auf, die Situation mit meinem Kik-Paket hat mir einfach gezeigt, dass NPM, das Ecosystem bzw. die Firma bzw. die Registry, someone's private land ist wo corporate also firmen mehr power als die einzelnen leute haben und seine philosophie ist er macht open source wegen power to the people. Finde ich sehr schön, das Statement. Und würd ich auch schon so unterschreiben. Ich bin mir nicht bewusst, ob der originale Open-Source-Autor ein richtiges Impact-Assessment hatte oder ob ihm wirklich bewusst war, dass LeftPad so viel genutzt wurde. Klar, in den Download-Statistiken. Aber Ende vom Lied war dann auf jeden Fall, dass ein Tag später der CTO von NPM, Lori Voss, eine spezielle Version von LeftPad un-unpublished hat. Somit wieder hochgeladen hat.

Wolfi Gassler (00:21:37 - 00:21:42)

Es ist ja auch, diese 11-Zeilen-Codes sind ja dann auch sehr hart wiederherzustellen.

Andy Grunwald (00:21:42 - 00:22:06)

Naja gut, er hat das Paket halt wieder hochgeladen oder beziehungsweise die Version 003 wieder verfügbar gemacht. Natürlich kann jetzt jeder sagen, okay, 11-Zeilen-Code, die kopiere ich mir in mein System, ist schon richtig. Ich glaube aber herauszufinden, warum von jetzt auf gleich, ohne dass irgendeine Modifikation in deinem Projekt gemacht wurde, herauszufinden, warum jetzt LeftPad unpublished ist, ich glaube, da investiert man schon mal in die eine oder andere Minute.

Wolfi Gassler (00:22:06 - 00:22:17)

Was ist denn jetzt auf gleich schon wieder für Ausdruck eigentlich? Jetzt auf gleich ist ja von... Gibt es das auf österreichisch? Jetzt auf sofort? Jetzt... Ich glaube den Ausdruck gibt es, das ist irgendwas aus dem Bot.

Andy Grunwald (00:22:17 - 00:22:51)

Ich würde sagen klassischer Bug. Jetzt auf gleich funktioniert halt nicht mehr, aber ich habe nichts gemacht. Okay, wo sind wir denn mit leftPath jetzt? leftPath, der Code ist immer noch auf GitHub, der wurde in eine Organisation umgezogen, da wurde der Maintainer geändert, aber leftPath selber ist offiziell deprecated, weil die Javascript-Standard-Library jetzt eine Funktion hat, die nennt sich petStart, die auf dem String-Datentyp arbeiten kann und die replaced eigentlich leftPath. Also, falls ihr noch leftPath in eurem Projekt habt, schmeißt es raus, ihr könnt das durch string.padstart ersetzen.

Wolfi Gassler (00:22:51 - 00:23:12)

Aber das war jetzt ein eigentlich noch positives Beispiel, weil das war ja nur, unter Anführungszeichen nur, dass ich nicht mehr compilen kann und mein Projekt gerade nicht mehr baubar ist, aber es war ja sozusagen nur eben das Verschwinden von diesem Code. Es gibt ja auch Beispiele, die sind wesentlich aggressiver und schädlicher. gibt es.

Andy Grunwald (00:23:12 - 00:24:39)

Kommen wir mal zum nächsten Beispiel. Das ist jetzt noch nicht ganz so schädlich, aber es hat auch für ein bisschen für ein bisschen Furore gesorgt. Und zwar geht es hier um den Fall der NPM Packages Color und Faker. Color selbst ist ein Paket, um Texte farblich zu machen und Faker ist ein Paket, um Fake-Daten für Tests und ähnliches zu erzeugen. Und dieser Inzident, der war Anfang dieses Jahres, 4. Januar 2022, also relativ frisch. Was ist passiert? Und zwar hat der Autor dieser beiden Pakete einen sogenannten Bug gefixt. Und zwar hat er es einen Zalgo-Bug genannt. Ein Zalgo-Bug ist ein Bug, wo bestimmte Non-ASCII-Character ausgegeben werden und so ein bisschen glitchy rüberkommen. Glitchy in diesem Kontext meint, dass die Buchstaben überlappen und ähnliches. Und wenn man das im Kontext von, ich mach mal einen Text farblich, sieht, dann macht das auch ein bisschen Sinn. Der GitHub-PR war halt also okay, fix Salgo-Bug. Was aber da gemacht wurde in diesem Pull-Request, er hat eine For-Loop oder eine Endlosschleife eingebaut, die konstant Liberty, Liberty, Liberty ausgibt, mit einer ASCII-Zeichnung von Uncle Sam, und der amerikanischen flagge das war aber.

Wolfi Gassler (00:24:39 - 00:24:44)

Dann von von von dem autor selbst oder von jemanden der pull request gesendet.

Andy Grunwald (00:24:44 - 00:26:27)

Hat das war von dem autor selbst der autor dieser beiden pakete die sehr sehr viel genutzt werden die haben auch eine sehr sehr große verbreitung, Er ist, ich nenne es mal, steil gegangen und hat den Code seiner eigenen Pakete modifiziert und hat diese sogenannten Seiteneffekte, und zwar Console-Logs in dieser Hinsicht, eingeführt. Die große Frage ist, warum hat er das gemacht? Und zwar hat er circa ein halbes Jahr davor, schon davor gewarnt. Und zwar war er mega, mega angepisst. Und ich schätze jetzt einfach mal, er war ein R. Er war mega mega angepisst, dass sehr sehr große Firmen, sogenannte Mega-Cooperations und kommerzielle Konsumenten von Open-Source-Projekten sich so auf Open-Source-Container stürzen und immer sehr sehr viel erwarten. Fix doch mal bitte diesen Bug, gib mir doch mal bitte Feedback. ohne einen Single Penny an die Entwickler zurückzugeben oder irgendwas für die Community zu tun. Und da hat er gesagt, hör mal, pass mal auf, ihr nutzt jetzt hier mein Color-Projekt und ihr nutzt hier mein Faker-Projekt, ihr könnt mir auch eine sechsstellige Summe an Gehalt zahlen. Und das hat ihn so heftig angepisst, dass er irgendwann die Reißleine gezogen hat. Wisst ihr was? Fickt euch alle. Ich zeige euch jetzt mal, was hier die Power ist und hat somit den Code von Color und Faker modifiziert mit dieser Endlosschleife, mit diesem Output, mit diesem Rubbish-Code. Also das bedeutet, falls ihr dann irgendwie ein NPM-Install gemacht habt, dann habt ihr alles gesehen, wie einfach nur Müll auf eurem CLI ausgegeben wurde und npm install wurde halt nie fertig weil halt einfach nur konstant irgendwelcher textmüll und natürlich liberty liberty liberty und ein ascii eine ascii zeichnung von uncle sam und der amerikanischen.

Wolfi Gassler (00:26:27 - 00:26:54)

Flagge ausgegeben wurde was immer noch besser ist als was mit note ipc damals passiert ist wo der auto den code so modifiziert hat dass wirklich Dateien, in dem Fall politisch motiviert, gelöscht worden sind und zwar nur auf Computern in Russland und in Weißrussland als politische Aktion und dieses Ding hat wirklich ein rekursives Delete aufgerufen und ist einfach von dem aktuellen Pfad nach oben gegangen und hat einfach alles gelöscht und durch Herzchen ersetzt.

Andy Grunwald (00:26:54 - 00:27:13)

Also wirklich eine andere Hausnummer, stimmt schon. Der Fall von Color und Faker hat aber auch ein paar größere Pakete betroffen, wie zum Beispiel das Amazons Cloud Developer Kit, AWS CDK, oder aber auch die populäre Testlibrary von Facebook, Jest. Somit könnt ihr euch natürlich vorstellen, dass das einen riesen Aufschrei gegeben hat.

Wolfi Gassler (00:27:13 - 00:27:41)

Und da sieht man schon, wie viel Einfluss eigentlich eine einzelne Person haben kann. Und in dem Fall sind es ja die Autoren, die im Normalfall eigentlich positiv gestimmt sind und darum haben sie ja auch Open Source entwickelt. Aber auch da gibt es natürlich solche Problemfälle. Aber es gibt natürlich auch das Sicherheitsrisiko, dass solche Libraries irgendwie gehackt werden zum Beispiel. oder in einer anderen Form irgendwie Schadcode eingeschleust wird. Und dann bekommt es der Autor oder der Maintainer gar nicht mal mit.

Andy Grunwald (00:27:41 - 00:29:01)

Das stimmt. Und so kommen wir zum dritten und letzten konkreten Fall, den wir heute mal besprechen. Und zwar geht es hier um eine sogenannte Attacke von NPM-Paketen, die nennt sich Typo-Squatting. Typo wie Vertipper. Und zwar geht es um das sogenannte Paket Cross-Env für Cross-Environment. Was hier passiert ist, es gibt ein populäres Paket, das nennt sich cross-env. Super viele Pakete haben das eingeführt, hat etwas mit Environment-Variablen zu tun. Was jetzt jemand gemacht hat, jemand hat den Namen cross-env ohne minus als Paket registriert. Das bedeutet, wir haben zwei Pakete, die einen fast identischen Namen haben, die sich nur um einen Bindestrich zwischen cross und env unterscheiden. Und jetzt kommt das faszinierende. Das originale Paket hat einen Bindestrich im Namen. Das fehlerhafte oder kompromittierte Paket hat keinen Bindestrich. Ist also von einem von einem Hacker, von einem Attacker oder ähnliches. Das kompromittierte Paket hat das originale Paket als Subdependency und das ist ja schon dreist, oder? Und hat als NPM Post Install Script Eine Aktion, die sagt, lese bitte alle Environment-Variablen aus und sende beim Post-Install des Pakets alle Environment-Variablen an den Server vom Hacker.

Wolfi Gassler (00:29:01 - 00:29:17)

Das heißt, wenn ich das irgendwo auf meinem Server laufen lasse, gerade heutzutage, wo alle Passwörter oder Keys jetzt, keine Ahnung, in Docker zum Beispiel, über die Environment-Variablen gesteuert werden, dann sendet der alle meine Passwörter und Keys an diesen Server.

Andy Grunwald (00:29:17 - 00:29:34)

Richtig, und da wir natürlich alle schön alles über Environment-Variablen steuern, weil wir machen ja alles mit 12-Factor-Apps, alles schön containerisiert und so weiter, sind mit hoher Wahrscheinlichkeit, wie du richtig sagst, GitHub-Tokens, Passwörter, Datenbankzugänge und, und, und da drin.

Wolfi Gassler (00:29:34 - 00:29:40)

Und dadurch das Originalpaket eingebunden wurde, funktioniert aber trotzdem alles, oder? Richtig?

Andy Grunwald (00:29:40 - 00:29:56)

Genau, ihr merkt das gar nicht. Nur beim npm install wird einmal kurz diese Prozedur von lese alle Variablen und machen curl request an den externen Server mit den ganzen Variablen, den ganzen environment Variablen. Ihr merkt gar nicht, was da los ist.

Wolfi Gassler (00:29:57 - 00:30:06)

Wobei, wenn es nur bei npm install passiert, dann passiert es nur auf meinem Rechner, wo ich das Ganze baue, oder? Im Live-Betrieb wird es dann nicht mehr gesendet.

Andy Grunwald (00:30:06 - 00:30:15)

Das ist korrekt, aber wir wissen auch alle, dass es sehr viele Firmen gibt, die immer noch ihre Deployment- und Produktionspakete auf den Kisten selbst bauen.

Wolfi Gassler (00:30:15 - 00:30:23)

Ja, oder unter Umständen einfach die Passwörter schon in der Dev-Environment drin haben oder die gleichen Keys. Das gibt es ja durchaus, ja.

Andy Grunwald (00:30:23 - 00:30:39)

Auch wenn du sagst, okay, ja, durch ordentliches Secret-Management, durch ordentliche Trennung von Environments, Dev-Stage-Production, durch ordentliche Deployment-Prozesse kann man die Attack-Surface, die Attack-Oberfläche deutlich mindern, das ist korrekt.

Wolfi Gassler (00:30:39 - 00:30:59)

Wobei in dem Fall ja, der hätte das auch senden können, wenn einmal die Library geladen wird. Inode zum Beispiel, also das wäre ja auch kein Problem. Also das war in dem Fall vielleicht ein glücklicher Zufall oder weniger professionell gemacht oder vielleicht, dass man es weniger schnell entdeckt, aber im Prinzip hätte das auch die produktiven Variablen betreffen können.

Andy Grunwald (00:31:00 - 00:31:02)

Wolfgang, wo kommt das ganze böse Blut her?

Wolfi Gassler (00:31:02 - 00:31:05)

Ja, man muss ja den Gegner kennen, um Sachen zu verhindern.

Andy Grunwald (00:31:05 - 00:31:41)

Ich glaube, wir haben grad den Autor von dem nächsten Typo-Squatting-Paket kennengelernt. Wie dem auch sei, das ist jetzt mal wirklich ein Inzident einer Attacke, die mit bösem Blut begangen wurde. Wohingegen natürlich bei Color und Faker oder bei Leftpad Ja ich will nicht sagen eine politische Motivation dahinter steckt aber schon in irgendeiner Art und Weise schon so ein Open Source rechte Gedanke. Das ist glaube ich eine andere Kategorie jetzt unabhängig davon ob das jetzt richtig war oder nicht weil man als Open Source Entwickler oder generell als Entwickler natürlich schon eine gewisse Verantwortung Dieses Typo Squatting.

Wolfi Gassler (00:31:41 - 00:32:46)

Wird ja auch ganz oft verwendet, wenn Firmen private Libraries haben, die sie selbst schreiben und durch irgendeinen Hackerangriff oder Daten, die nach außen gelangen, findet man irgendwie heraus, wie diese internen Pakete heißen und man publisht dann ganz normal in NPM Public-Pakete, die gleich heißen und wenn dann irgendwo was in der Konfiguration nicht stimmt beim Bauen, dann kann es sehr leicht sein, dass die Public-Pakete die privaten Pakete überschreiben und dann hat man plötzlich irgendeinen fremden Shardcode auf seiner Maschine und man führt den vor allem aus, also auch wenn das nur in der Dev-Umgebung ist, man führt plötzlich Shardcode aus und das ist natürlich ein ganz klassisches Problem, dass man auf jeden Fall verhindern sollte, weil auch wenn es nur in der Dev-Environment ist, gibt man da trotzdem extrem viele Informationen nach draußen und das hilft halt dann vor allem Hackern, um dann weitere Schlupflöcher zu finden, Informationen zu bekommen, auszuspionieren und das dann weiter zu verwenden oder zu verkaufen. Da gibt es ja viele Möglichkeiten. Also dieses Type Squatting ist ist es ja vielseitiges Einfallstor.

Andy Grunwald (00:32:46 - 00:33:52)

Typosquatting wird auch sehr viel im Domainsektor angewendet. Klassisches Beispiel ist ein kleines L und ein großes I. In bestimmten Schriftdaten sieht das nämlich ganz genau aus. Da müsst ihr auch ein bisschen aufpassen. Oder sehr viele griechische Buchstaben sehen sehr ähnlich aus wie normale deutsche Buchstaben, wo dann zum Beispiel ein E sehr gleicht, obwohl das sind einfach zwei verschiedene ASCII-Charakter. Und somit kann Typosquatting da auch angewandt werden das waren aber jetzt nur drei konkrete beispiele von diversen anderen beispielen welche welche arten welche pattern von incidents welche anderen methoden gibt es denn noch wir haben jetzt wir haben jetzt drei stück besprochen und zwar einmal code geändert durch den owner Sei es politisch motiviert, wie zum Beispiel Color und Faker. Wir haben einmal das Unpublishing oder das Löschen von Paketen angesprochen, wie zum Beispiel in dem Falle von Leftpad. Und wir haben einmal Typosquatting angesprochen. Was gibt's noch für Fälle?

Wolfi Gassler (00:33:52 - 00:35:38)

Also ganz grundsätzlich ist es ja immer das gleiche. Es wird irgendwie ein Schadcode oder böser Code oder falscher Code eingeschleust. Und die Frage ist eben, welche Möglichkeiten gibt es, um das einzuschleusen. Eine sehr ähnliche Variante zu dem von Leftbird besprochenen Beispiel, wo der Owner eben aus politischen Gründen zum Beispiel etwas ändert oder Schadcode einschleust, ist auch der Wechsel von Maintainern. Das heißt, Ganz oft suchen Open Source Projekte neue Maintainer oder nehmen Leute mit rein, zum Beispiel, dass die auch Maintainern werden. Wie du ja richtig gesagt hast, es kommen da extrem viele Pull Requests, neue Features. Das Projekt wächst und man braucht mehr Leute, um das einfach zu verwalten. Und dann gibt es vielleicht irgendwelche Maintainer, die stellen sich im ersten Moment als sehr gut da, machen ein paar Pull-Requests, helfen und kommen dann mit rein. Aber es ist natürlich wie überall, auch wenn du neue MitarbeiterInnen oder so anstellst in deiner Firma, du weißt natürlich erst nach einer Zeit, wie die drauf sind und die können sich natürlich dann vielleicht als Hacker am Ende entpuppen und als Maintainer irgendwie Shardcode eingeschleust haben. Oder man übergibt das Projekt komplett an den neuen Maintainer zum Beispiel und dann stellt sich heraus nach einer gewissen Zeit, okay, dieser Maintainer hat böses Blut in den Adern und probiert eben da seine Stellung, seinen Machteinfluss zu missbrauchen. Also auch da wieder selbes Problem, Schadcode, der eingeschleust wird, aber über einen anderen Weg, über einen neuen Maintainer. Und für dich als normaler Entwickler ist das ja meistens gar nicht transparent. Du kennst ja nicht von diesen, wie erwähnt, 780 Dependencies, die Maintainer, ob sich da irgendwas geändert hat. Also da hat man null Einblick, da muss man eigentlich fast drauf vertrauen.

Andy Grunwald (00:35:38 - 00:36:30)

Genauso ähnlich sieht es bei Subdependencies aus. Ich hatte gerade gesagt, oder ich hatte in der Einleitung gesagt, dass die meisten LMPM-Pakete einen kleinen Fokus haben auf ein reduziertes Feature-Set, damit die Code-Basis maintainbar bleibt von einer Person. Und das führt natürlich dazu, dass auch Libraries sich auf andere Libraries stützen als Dependencies, um Funktionalitäten nicht selber schreiben zu müssen. Das bedeutet natürlich auch, wenn ihr einfach mal ein Library hochzieht, könnte es natürlich sein, dass durch eine neue Version in einer Sub- oder Sub-Dependency neuer Shardcode mit reinkommt. Natürlich könnt ihr immer alles auditen und immer jeden Commit von einem anderen Maintainer überprüfen, aber im Endeffekt verlasst ihr euch natürlich auf eine Dependency und ihr holt euch diese natürlich rein, damit ihr diese Arbeit nicht doppelt tun müsst. Und wenn ihr jetzt alles kontrolliert, könnt ihr machen, aber dann ist wirklich die Frage, ob ihr dann nicht den Code selber schreiben solltet.

Wolfi Gassler (00:36:30 - 00:37:09)

Was natürlich auch noch passieren kann, ist, dass einfach der Account von dem Maintainer gehackt wird. Da probiert natürlich jetzt GitHub einiges, dass man Two-Factor-Authentication dabei hat und das nicht mehr so einfach möglich ist, weil gerade wenn das irgendwie ein sehr großer Account ist oder ein sehr bekannter Account, der irgendwie viele Libraries hat oder sehr wichtige Libraries hat, dann ist das natürlich auch ein Angriffsziel für viele Hacker, weil die dadurch wieder dann Code einschleusen könnten in extrem viele Firmen und das natürlich dann auch dementsprechend ein großer Punkt ist. Da kann man mittlerweile mehr auf GitHub und Co. vertrauen, weil die einfach auch probieren, da möglichst die Dinge abzusichern, weil es ja auch in deren Interesse ist.

Andy Grunwald (00:37:09 - 00:37:54)

Genau, und da sind wir im Bereich Social Hijacking und Social Engineering. Da muss man ganz aufpassen. Wenn ein, jetzt mal angenommen, der Wolfgang hat ein NPM-Package, das hostet er auf GitHub und publisht das in die NPM-Registry. Wenn ich Wolfgangs NPM-Account übernehme, heißt das, Ich bin in der Lage, eine existierende Paketversion in der NPM Registry mit meinem Shardcode zu überschreiben, ohne das dahinterliegende Git-Repository zu modifizieren. Das bedeutet, ihr kriegt es eigentlich gar nicht mit, dass Und auch Wolfgang kriegt es nicht mit, dass in seinem Paket Shardcode drin ist, weil das originale Git-Repo wurde ja gar nicht modifiziert. Und das ist eine sehr gefährliche Geschichte.

Wolfi Gassler (00:37:54 - 00:37:58)

Wobei mittlerweile NPM ja mit GitHub zusammenhängt, oder meines Wissens?

Andy Grunwald (00:37:58 - 00:38:00)

NPM wurde von GitHub gekauft.

Wolfi Gassler (00:38:00 - 00:38:10)

Und damit auch höchstwahrscheinlich dass dasselbe Account ist. Also wenn mein GitHub-Account gehackt wurde, dann ist das dasselbe wie NPM. Also die Authentifizierung läuft wahrscheinlich über GitHub.

Andy Grunwald (00:38:10 - 00:38:22)

Also jetzt gerade eine sehr gute Frage, ob das bereits migriert wurde, zusammengeführt wurde, weiß ich gerade nicht, weil du kannst dir vorstellen, ich bin jetzt nicht der große Autor von sehr vielen NPM-Paketen, weil.

Wolfi Gassler (00:38:22 - 00:38:25)

JavaScript einfach deine Sprache ist, das wissen wir ja schon.

Andy Grunwald (00:38:25 - 00:39:08)

Als letzte Art von Incident hätte ich noch eine Sache, die sehr viel die Firmen betrifft. Und zwar geht es nämlich um die NPM Registry selbst. Viele Firmen haben private NPM Pakete, die sie nicht Open Source machen wollen, wie zum Beispiel irgendwelche Banken, die dann gegebenenfalls proprietären Code haben. Da kann es natürlich sein, weil die Barriere so niedrig ist, ein neues NPM-Paket zu veröffentlichen. Das ist unter anderem auch ein Grund, warum es so viele NPM-Pakete gibt, weil die Barriere so niedrig ist. Jeder kann durch NPM-Publish und dann einen Namen, ein neues Paket in die Welt setzen, in die Public Registry setzen. Das kann natürlich auch dazu führen, dass ProProterra Firmencode ganz einfach in die falsche Registry gepusht wird.

Wolfi Gassler (00:39:08 - 00:39:37)

Oder wenn man da mal vergisst, einfach dieses Private True zu setzen in der Definition, dann kann es sehr schnell gehen, dass irgendwo plötzlich dieser eigentliche private Code, der für niemanden bestimmt ist, plötzlich in der Öffentlichkeit landet. und dann natürlich wieder verwendet werden kann, um vielleicht Informationen zu bekommen über das Naming, über andere Pakete, dann kann man eben wieder diese Paketnamen verwenden, um eigene Pakete zu erstellen und in der Hoffnung, dass die dann überschrieben werden und so weiter.

Andy Grunwald (00:39:37 - 00:40:47)

Und dann hat die Firma natürlich die Kacke am Dampfen. In der Regel ist schon ein paar mal passiert, dass zum Beispiel eine populäre Bank ein privates Paket in die Public NPM Registry gepusht hat. Und dann geht's natürlich an sogenannte DMCA-Takedowns. Das ist nach dem amerikanischen Recht eigentlich so ein Brief. Hey, pass mal auf, ich habe die Rechte an diesem Paket, bitte nimm das runter. Github macht alle DMCA, Takedown Notices, öffentlich in einem Repository und da könnt ihr zum Beispiel gucken, wer welche Anfrage stellt, um welches Github Repository sperren zu lassen. So auch geschehen, ich glaube, mit YouTube Downloader vor nicht allzu langer Zeit. Genau, also falls das euch passiert, ihr könnt zusehen, dass das Paket wieder runtergenommen wird. Ihr könnt natürlich nicht verhindern, dass das Paket nicht schon 10 Millionen mal runtergeladen hat. Jetzt haben wir natürlich über diverse Patterns von Inzidenz gesprochen. Lass uns mal bitte darüber sprechen, was wir als einzelne Entwickler oder wir als Firmen denn eigentlich dagegen tun können, beziehungsweise wie können wir uns selbst vor diesen Arten von Inzidenz schützen.

Wolfi Gassler (00:40:47 - 00:44:39)

Bleiben wir vielleicht gleich bei dem erwähnten Problem, dass der Private Code überschrieben wird, wenn ich jetzt eine private Library zum Beispiel verwende. Also da gibt es in NPM mittlerweile diese Scopes, die mit diesem Add, das haben vielleicht viele schon gesehen, dass man da Add und dann den Scope, den Firmennamen zum Beispiel verwendet. dann ist das schon wesentlich schwieriger, weil das dann wirklich klar ist, zu welcher Firma das gehört. Man kann das dann auch zu gewissen User-Accounts pinnen, dass das nicht jeder überschreiben darf, diesen Scope. Dann kann gar niemand in diesem Scope irgendwelche Pakete publishen. Wenn man NPM Enterprise verwendet, also einen lokalen Proxy zum Beispiel, dann kann man das dementsprechend auch sagen, welche Scopes überhaupt erlaubt sind, privat, public und so weiter. Also da kann man viel konfigurieren, muss natürlich auch richtig konfigurieren. Ganz klar, aber mit dem kann man dann schon viel abblocken und das ist halt auch ganz klassisch wichtig, wenn man sich irgendwie so ein NPM Enterprise oder ein Proxy reinholt, dass man den eben nicht nur blind installiert, sondern hat sich auch wirklich überlegt, okay, welche Sicherheitsmaßnahmen muss ich da setzen, kann man gern auch an Artikel verlinken, damit man eben diese Grundkonfiguration richtig macht, um da kein zusätzliches Einfallstore aufzumachen. Was wir auch schon angesprochen haben ist, was GitHub natürlich macht, also da brauchen wir gar nichts als Developer machen, die probieren natürlich das ganze zu verbessern, dass keine Accounts highgecheckt werden, die prüfen auch teilweise auf Shardcode, wobei das natürlich extrem schwierig ist, aber sie sagen, sie probieren das natürlich auch, also da wird schon auf vielen Fronten gekämpft, aber natürlich Die Frage ist, was wir auf unserer Seite machen können als Developer. Und um ehrlich zu sein, wir sind da ziemlich eingeschränkt, weil wenn du 780 Dependencies zum Beispiel hast, Runtime Dependencies, du kannst nicht in den Code schauen, du kannst nicht da ständig alle Änderungen durchchecken. Was hat sich denn in der achten rekursiven Ebene wirklich geändert? Aber was man natürlich schon machen kann, ist, man kann die direkten Dependencies überwachen zumindestens. Was wurde dort geändert? Im Change Log reinschauen, das wirklich sauber durchtesten, dann kann man vielleicht einmal gewisse Sachen verhindern oder zumindest frühzeitig erkennen. Und was in dem Kontext ganz, ganz wichtig ist, ist, dass man einfach die Versionen, die man verwendet in seinem Package.json oder in seinem Composer.json in php oder was man auch für die Dependency Management System verwendet, dass man dort einfach die Versionen fest pinnt oder festzut, also dass man wirklich die genaue Versionsnummer 3.4.5 Alpha oder 0.0.0.1 bei Undesign Ästhetics Side Generator, die ihr verwendet, die irgendwie in der Pre-Alpha vorkommen, dass man die einfach festzud, weil man ja nie weiß, was für Changes kommen und was die mit sich bringen. Das ist auf der einen Seite, natürlich sollte man das allgemein machen als Entwickler, weil man einfach auch mit Änderungen, Breaking Changes unter Umständen Probleme hat. Aber eben auch gerade wenn es um Security geht, ist es sehr wichtig und wenn man dann noch dieses Glück hat, dass man sehr faul ist und vielleicht nicht sofort updatet am nächsten Tag, dann haben das vielleicht in der Zwischenzeit schon andere gelöst, eine Woche später, weil üblicherweise gerade wenn es bekannte Pakete sind, dann kommt man da höchstwahrscheinlich schon drauf und dann hat man da vielleicht auch noch ein bisschen Frist und kann sich wirklich überlegen, okay, will ich dieses Update wirklich schon fahren, wenn das gestern gepublished wurde, oder warte vielleicht noch eine Woche. Das schadet ja grundsätzlich auch nie, da ein bisschen zu checken, okay, was sind es für Änderungen, ist das ein Major Release, ist das ein Minor Change, was das auch immer ist, dass man das also wirklich unter Kontrolle hat und da auch wirklich in die Details reingeht.

Andy Grunwald (00:44:39 - 00:46:09)

Version, bis auf die letzte Ziffer festzuholen, ist eine gute Sache. Hat den Riesenvorteil, dass ihr euch sicher sein könnt, dass von heute auf morgen euer Nightly-CI-Build nicht failt, weil irgendein Regression in der letzten Version, in der meiner Version irgendwie reinkommt. Weil ziemlich viele Leute machen so was wie 1.0.Sternchen. Und somit seid ihr aktuell auf der Version 1.0.2. Beim nächsten NPM-Install seid ihr automatisch auf 1.0.3. Da kann natürlich auch sehr viel kaputtgehen. Hat aber auch den Nachteil, dass ihr auch jedes Miner, jede Miner-Version natürlich hochziehen müsst. Ja, also das bedeutet ein bisschen mehr Upgrade-Aufwand. Wie dem auch sei, wichtig zu wissen, wenn ihr die Version auf die letzte Zahl festzuhrt, das schützt euch nicht, dass eine existierende Version nicht mit Chartcode überschrieben wird, wie zum Beispiel in dem Fall, wenn ein NPM-Account geheijackt wird oder das Git-Tag gelöscht und neu angelegt wird oder ähnliches. Das schützt euch nicht davon. Viele Paketmanager supporten aber sowas wie, ihr gebt eine Version an, Version 1.0.2, add, und dann einen Git-Share. Und dieser Git-Share sorgt dafür, wenn ein existierendes Git-Tag überschrieben wird, dass dann das Git-Share nicht mehr passt. Ja, weil das ist ein SHA1-Hash, der geht auf den Content des Comets, Und somit seid ihr sicher, dass, wenn das Originalpaket, das Original-Tag überschrieben wird, dass ihr einen Fehler kriegt, weil dieser Git-Schal nicht mehr gefunden werden kann.

Wolfi Gassler (00:46:09 - 00:46:28)

Wie ist das eigentlich, wenn jetzt die Versionsnummer gleich bleibt, aber der Code sich ändert? Wird das überhaupt neu runtergeladen? Checkt das überhaupt ein NPM? Also beim normalen Update wahrscheinlich nicht, oder? Weil da ja wahrscheinlich nur die Versionsnummer gecheckt wird. Vermute ich mal. Ich kenn die Implementierung nicht.

Andy Grunwald (00:46:28 - 00:47:41)

Genau, ich glaub, es kommt auf die Implementierung an. Nehmen wir mal zwei Cases. Für deinen lokalen Entwicklungsrechner wird's sehr wahrscheinlich aus dem lokalen Cache gezogen, weil du dann mit hoher Wahrscheinlichkeit sagst, oh, die Version 1.0.2 hab ich schon. Fürs CI-System, was natürlich immer nur clean startet, natürlich nicht, ja? Weil dein Prod-Deployment hat ja hoffentlich keinen lokalen Cache, sondern startet immer in einem fresh State. Und somit wird dann natürlich immer die affected Version ausgezogen. Was dann noch eigentlich viel schlimmer ist, weil du natürlich dann in Produktion eine andere Version laufen hast als bei dir lokal und du denkst, du hast dieselbe Version. Ist ja noch viel schlimmer. Deswegen, Gitcha hintendran. Somit könnt ihr euch sicher sein, dass das wirklich das Tech ist. Klar, bei einem Versionsupgrade muss dann natürlich auch das Gitcha hochgezogen werden. Bisschen mehr Arbeit, ja? Aber ganz im Ernst, für diese bisschen mehr Arbeit, da gibt's zum Beispiel so was wie Dependabot, Der kann sowas auch. Soviel ich weiß unterstützt er bei ein paar Paketmanagern ebenfalls diesen Gitschar hinten dran. Und das gleiche wird nämlich auch von GitHub selbst für GitHub Actions empfohlen. Da könnt ihr es auch, wenn ihr in der externe GitHub Action nutzt, könnt ihr Version 1.0 add Gitschar. Die empfehlen sowas nämlich auch in der offiziellen Dokumentation. Verlinken wir natürlich auch in den Shownotes.

Wolfi Gassler (00:47:42 - 00:47:45)

Was ist dieser Dependabot? Kannst du das nochmal schnell erklären?

Andy Grunwald (00:47:45 - 00:48:40)

Ah, Dependabot ist unser Lieblingsthema. Automation, Automation, Automation. Was Dependabot ist, das ist ein Tool, wurde inzwischen von GitHub gekauft, kann in euer GitHub-Repository eingeklinkt werden und dahinter legt ihr eine kleine Config und sagt, da ist meine Package, da ist mein GitHub-Actions-Workflow und Dependabot checkt dann In einem zu definierenden Intervall, sagen wir mal alle zwei Tage, ob es von deinen Dependencies neuere Versionen gibt, macht dann automatisch pro Paket einen Pull-Request mit Change-Log, mit Upgrade-Path und so weiter und so fort und ihr könnt euch dann in dem Pull-Request zu entscheiden, okay upgrade ich, merge ich oder nicht. Das bedeutet ein komplettes Upgrade Pattern wird automatisiert und ihr könnt dann jede einzelne Dependency updaten oder nicht. Das befreit euch natürlich nicht von dem Sub Audit, was ihr euch da rein holt, was ihr da upgradet, aber Dependabot packt wenigstens die Release Notes und das Change Log mit rein, sofern vorhanden.

Wolfi Gassler (00:48:41 - 00:49:31)

Und man wird einfach daran erinnert, dass da eine neue Version ist, weil das ist ja auch das größte Problem, zumindest mein Problem, ehrlich gesagt, wenn man da irgendwo eine Version festzog, wie oft checkt man denn wirklich, gibt's da eine neue Version und dann, dass man sich wirklich hinsetzt, okay, was waren die Changes. Klar sollte man das machen, aber je nachdem wie wichtig das Projekt ist, macht man das halt einmal oder einmal auch nicht und wie viel Zeit man hat und die Bender-Bot erinnert einen da halt immer schön über einen Pull-Request und was da auch noch ganz schön ist, wenn man da eine saubere Pipeline hinterlegt hat, dann gehen da auch sofort alle Tests durch, vielleicht wird schon eine Preview generiert, wenn es jetzt irgendwas mit Oberfläche ist oder eine Webseite. Dann kann man sich sofort das Ergebnis anschauen und checkt mal, ist da irgendwo ein Fehler, gibt es da irgendwie Probleme oder ist das einfach eine kleine Änderung, die ich sofort durchwinken kann.

Andy Grunwald (00:49:31 - 00:50:12)

Eine Sache muss man dennoch sagen. Upgradet nicht nur immer nur das Upgradet wegen. Springt nicht immer sofort auf die Next-to-Major-Version. Auch diese Entwickler können Bugs produzieren. Die können euch auch hinten drauf fallen. Vielleicht wartet ihr mal bei großen Changes ein bisschen auf ein paar meiner Versionen, bis die ersten Kinderkrankheiten raus sind. Ab und zu ist es auch völlig okay, auf einer älteren Version stabil zu bleiben. Man muss nicht immer komplett dem Next-to-Major-Scheiß hinterherlaufen. Wenn ihr natürlich in irgendeiner Art und Weise Debucation-Notices kriegt oder die ganze Sache einfach nicht mehr maintained wird, dann solltet ihr natürlich gucken, dass ihr schon auf aktuellere Software geht. Ich sag nicht, lasst eure Software verhalten, sondern ich sag ...

Wolfi Gassler (00:50:12 - 00:50:22)

Doch, doch, du hast es genau gesagt. Und ich werd es in Zukunft auch als Argument bringen. Andi hat mir gesagt, macht keine Updates. Da kann ich mich mal zurücklehnen. Nur wenn's wirklich problematisch wird.

Andy Grunwald (00:50:22 - 00:51:51)

Das stimmt nicht. Ich sag nur, neuer ist nicht immer besser. Ja, ein bisschen mit der Balance betrachten. Der Fachterm nennt sich Version Drift. Da könnt ihr mal nachgoogeln. Version Drift besagt aus, wie weit eure Dependencies von den letzten Updates wegdriften. Und das ist auch eine Code-Metrik, ähnlich wie die Endpass-Komplexität oder die zyklomatische Komplexität, die ihr natürlich auch mal monitoren könnt. Es gibt natürlich noch ein paar andere Thematiken wie Container-Scanning, Security-Scanning, dass ihr vielleicht mal irgendwie einen Bot in euer Slack holt, der auf aktuelle Sicherheitsissues, CVEs und Ähnliches euch informiert. Ihr könnt natürlich auch so etwas teurere Lösungen wie GitHub-Security und CodeQL anwenden. Also in dem Spektrum, in dem Sektor gibt es unglaublich viel, was ihr machen könnt. Dennoch ein paar low-hanging fruits. Account-Security, zwei-Faktor-Notification bei NPM. Paketversionen festsuchen, lokale Repository-Mirrors in eurem Firmennetzwerk zu haben, um zum Beispiel euch vor Package-Deletion und Package-Unpublishing zu schützen, NPM-Scopes mit dem Ad oder vielleicht ein bisschen die Upgrades ein bisschen automatisieren. Macht euch das Leben leichter, hilft euch nicht wirklich bei Security, aber hilft euch ein bisschen mehr Awareness zu kriegen, was wann ihr wie wo geupdatet habt, mit natürlich der schnellen Optionen des Git-Revert und Comet-Reverting und dem Rollback.

Wolfi Gassler (00:51:51 - 00:52:40)

Und natürlich ganz allgemein, was immer eine gute Möglichkeit ist, bevor man eine Dependency einbindet, wirklich checken, braucht man die Dependency, kann ich vielleicht nur den Code kopieren, wenn es 11 Zeilen sind, dann fällt mir nämlich die Maintenance weg von der Dependency. Und dann, wenn ich auswähle, okay, ich brauche diese Library unbedingt, ist es eine gute Library? Wie viele Maintainer sind dahinter? Wie viele Nutzer gibt es? Weil dann kommt man auch früher drauf, wenn irgendwo ein Problem ist, natürlich, wenn eine Million andere User auch diese Library verwenden und dementsprechend einfach auf Qualität achten und nicht einfach blind, okay, diese Library macht, was ich brauche, blind einbinden und nicht mehr darüber nachdenken. sinnvoll Libraries einbinden mit Bedacht und dann hat man normalerweise, wenn man eine höhere Qualität einbindet, auch weniger Sicherheitsprobleme klarerweise.

Andy Grunwald (00:52:41 - 00:53:45)

Deswegen bin ich auch ein Riesenfan von Go, von Golang, von der Sprache, die damals von Google erfunden wurde. Die sind sehr auf Pragmatismus aus und die sind genau sehr, sehr bedacht, was neue Dependencies angeht. Und die sagen auch, okay, wenn du eine Library haben möchtest, wie viel Code brauchst du denn wirklich? Vielleicht ist das nicht okay, wenn du einfach nur die 100 Zeilen eben rüberkopierst in dein eigenes Modul. Hat natürlich dann auch ein paar andere Nachteile, dass du dann 100% verantwortlich bist für diese 100 Zeilen, aber machen wir uns nichts vor, wenn du eine externe Dependency reinholst in deine Software, bist du ja für die Software so oder so verantwortlich. Also von daher befreit sich das nicht, aber ich finde, das ist auf jeden Fall ein anderes Mindset als das JavaScript-Ekosystem, was in der Regel sagt, oh, da hinten gibt es eine Library, ich nutze aber nur eine Funktion, dann hole ich mir aber die ganze Library. Das generalisiere ich natürlich, weil es gibt, glaube ich, auch die eine oder andere Firma, die sehr, sehr bedacht damit umgeht mit externen Libraries und guckt sich ganz genau an, was ich mir da reinhole, weil Fehler suchen ist natürlich auch immer tricky später, aber deswegen mag ich auf jeden Fall den Pragmatismus von Go.

Wolfi Gassler (00:53:45 - 00:53:56)

Ja, wir sind es ja schon gewöhnt, dass du ganze Gruppen beleidigst, sei es deutsche oder in dem Fall wieder JavaScript-Entwickler. Ist vollkommen okay, wir freuen uns auf die ganzen Tweets, die wir dann Als antwort bekommen ich bin ich bin ich.

Andy Grunwald (00:53:56 - 00:54:17)

Bin ich bin immer ein freund von einem gesunden streit von einem gesunden konflikt ja wir können wir können gerne über alles diskutieren solange wir objektiv objektiver ebene bleiben und und nicht persönlich werden und wirklich auf auf den auf den vielleicht sogar auf den fakten basiert und aber für mich ist wichtig dass wir danach alle noch ein bierchen trinken können oder vielleicht wieder wie der wolfgang gerne mal so ein säckchen oder schampanier ein bisschen blubberwasser.

Wolfi Gassler (00:54:17 - 00:54:55)

Ja, genau. Okay, auf jeden Fall, wenn ihr dann nicht einverstanden seid mit Andis Verallgemeinerungen, würden wir uns natürlich freuen auf Feedback, entweder auf Twitter unter ING Kiosk oder auch bei E-Mail direkt an Andi. Wir sollten nochmal eine direkte E-Mail-Adresse für dich einrichten, weil ich glaube, die Beschwerden kommen eh nur immer zu dir. Aber haben wir leider noch nicht. Also stetig at engineeringkiosk.dev. Ich werde Feedback, Vorschläge, bitte alles einfach an uns senden. Wir freuen uns über alles. Auch über irgendwelche Audio-Files, wenn ihr mal wollt. Irgendwie ein Audio-Feedback. Wir bauen das dann auch gerne in kommende Folgen mit ein. Überhaupt kein Problem.

Andy Grunwald (00:54:55 - 00:54:59)

Wie wird dann meine E-Mailadresse aussehen? robotassi at engineeringkiosk.dev oder?

Wolfi Gassler (00:54:59 - 00:55:01)

Das klingt gut. Ich werde es mal einrichten.

Andy Grunwald (00:55:01 - 00:55:23)

Okay, dann könnt ihr natürlich auch eure Audio-Rants gerne an ruhrpottassi at engineeringkiosk.dev senden oder vielleicht machen wir einfach mal irgendwie so ne WhatsApp-Krieg. Gibt's WhatsApp for Business noch? Dann können wir einfach ne WhatsApp-Nummer einrichten, irgendwie über Twilio oder so. Und dann können die Leute mir irgendwie schön ihr Gefluche, also nicht wenn sie auf dem Klo sitzen oder so, schön per Sprachnachricht senden.

Wolfi Gassler (00:55:23 - 00:55:27)

Ich glaub, wir führen sowas ein. Wir werden das noch dementsprechend völlig Ich.

Andy Grunwald (00:55:27 - 00:55:48)

Hoffe, ihr hattet ein bisschen Spaß bei diesen NPM-Package-Inzidenz. Wie am Anfang bereits gesagt, das kann natürlich jeden Paketmanager treffen. Und wir haben natürlich ziemlich viele andere Paket-Inzidenz nicht besprochen, wie zum Beispiel UserAgentParser.js oder PureScript. oder ähnliches, in dem ganzen Ecosystem oder Event-Stream, aber auch ein schönerer Inzident.

Wolfi Gassler (00:55:48 - 00:55:59)

Können wir aber gern noch die verlinken, wer da mehr drüber lesen will über andere Inzidents. Gibt aber ganz coole und interessante Geschichten, bis zu ganz vielen Bitcoin-Klau-Geschichten.

Andy Grunwald (00:56:00 - 00:56:03)

Ansonsten lassen wir euch jetzt allein in.

Wolfi Gassler (00:56:03 - 00:56:06)

Dem Audit von eurer Package.json die Bannensee heilen.

Andy Grunwald (00:56:06 - 00:56:11)

Und viel Erfolg beim Versionen-Festsuchen. Tschüss! Ciao!