00:00:00: Hallo und herzlich willkommen zu der zweiten Episode von Library Nightmare, moderne Package Manager und Open Source. Viel Spaß!

00:00:25: Aber das ist eine super Überleitung zu dem zweiten Thema.

00:00:29: Das ist wahrscheinlich jetzt die doppelte Überleitung.

00:00:32: Aber wir haben in dem zweiten Teil jetzt sowohl einen alten als auch einen neuen Fall, der

00:00:38: damit super Hand in Hand läuft mit dem, was wir da jetzt gerade besprochen haben.

00:00:41: Und zwar habe ich eine Studie gelesen von der TU Darmstadt, die ist jetzt zugegeben

00:00:48: ermaßen auch nicht ganz aktuell.

00:00:49: bei solchen Frameworks und bei solchen Themen, wie wir sie jetzt gerade besprochen haben,

00:00:55: natürlich auch schon mal echt einen riesen Unterschied darstellen kann, weil sich in diesem

00:00:59: Ökosystem so unheimlich viel tut. Aber diese Studie, die ich gelesen habe, die ist von 2019

00:01:06: von der TU Darmstadt und die beschäftigt sich mit der Sicherheit im NPM Ökosystem. Und da gibt es

00:01:11: einige Beispiele, die da angezogen werden und die möchte ich gerne mit anbringen an das Thema

00:01:18: "Left Pad", was von 2016 ist. Da werden wir immer mal wieder den Bezug zu unserem ersten Teil jetzt

00:01:23: hier ziehen, weil es ziemlich viele Parallelen gibt und auch ziemlich viele Ähnlichkeiten,

00:01:28: was unseren Vorschlag angeht, damit umzugehen. Und das möchte ich gerne mit diesen wissenschaftlichen

00:01:34: Informationen, die sich jemand mit sehr viel Mühe zusammengetragen hat. Ich spare mir jetzt,

00:01:38: die einzelnen Namen der Autoren zu nennen, aber das kann man dann ganz gerne nachlesen hinter

00:01:43: der Quelle, die in der Folgenbeschreibung heute auch nachzulesen sind. Die beschäftigen sich

00:01:50: damit und die haben sehr viele tolle Fakten oder weniger tolle Fakten zusammengetragen,

00:01:56: die ich jetzt gerne unterfütternd neben dem Thema Leftpad unterbringen möchte.

00:02:00: So, im Jahre 2016 ist das Ähnliches passiert, wie wir jetzt mit ColorJS sehen. Nur mag man

00:02:10: man es jetzt drastischer nennen oder mag man es konsequenter nennen. Aber der Autor von

00:02:18: Leftpad hat sich 2016 dazu entschieden, 250 seiner Pakete, die er auf NPM zur Verfügung

00:02:25: gestellt hat, von einem auf den nächsten Moment zu unpublishen. Das heißt, er hat

00:02:31: letztendlich sich dazu entschieden, das nicht wie der Vorgänger hier aus unserem Podcast

00:02:37: zu sabotieren aktiv, sondern er hat von jetzt auf gleich entschieden, nein, mein Code, den

00:02:41: ich öffentlich zur Verfügung gestellt habe, den möchte ich jetzt nicht mehr unter meiner

00:02:45: Flagge über einen Pem weiteren vertreiben oder allen Leuten zur Verfügung stellen.

00:02:50: Finde ich, es im ersten Moment sagt es ein bisschen mehr Konsequenz aus, ein bisschen

00:02:56: weniger, wir wollen es jetzt nicht wieder sagen, aber kriminelle Energie. Mir ist jetzt

00:03:02: so wirklich bekannt, dass da ein großes Statement drauf gefolgt hat, wo er irgendwelche politischen

00:03:07: Ansichten oder irgendwelche Conspiracies oder sowas veröffentlicht hat, sondern er hat 250

00:03:12: seiner Packages erstmal unpublished und hat natürlich dann die Auswirkungen auch erstmal

00:03:17: sehen können und auch verfolgen können. Ich glaube, es gibt eine Aussage von ihm auch dazu,

00:03:22: warum er das gemacht hat und wie er das gemacht hat, aber wir möchten uns jetzt einfach mal mit

00:03:26: den Auswirkungen nochmal beschäftigen, was da denn passiert ist. So, im Endeffekt,

00:03:30: Leftpad besteht aus nicht mehr als 11 Zeilen Code. Das ist zugegebenermaßen auch immer

00:03:38: wieder ein lustiger Punkt gewesen, wenn ich mich mit meinen Kollegen darüber unterhalte,

00:03:42: für was man denn andere Frameworks einbezieht oder was ist denn der typische Fall, den ich in einem

00:03:48: JavaScript-Projekt oder im Node.js-Projekt als Libraries, als Abhängigkeiten mit in mein Projekt

00:03:54: hole, um Aufgaben für mich zu erleichtern. Dann ist vielleicht jetzt dieses Left Pad von 2016,

00:04:00: der Incident, ein bisschen lustig, weil diese Elfzeilen-Code, die haben nicht wirklich viel

00:04:05: mehr gemacht, außer einen String zu manipulieren. Auf eine Art und Weise, ich sage es schon mit 11

00:04:09: Lines of Code, das kann man auch selber schreiben. Man kann sich diesen Code auch angucken, kann sich

00:04:17: den Teil davon adaptieren, den man selber für sich braucht oder davon, ich nenne es mal,

00:04:22: inspirieren lassen. Ich schreibe mal einen Code, der das tut und gucke mal rein, ob sich derjenige,

00:04:27: der dieses Framework oder diese Library oder dieses Framework ausgedacht hat, hat er vielleicht

00:04:33: einen Meter weitergedacht. Dann lasse ich mich davon vielleicht noch mal inspirieren an der Stelle.

00:04:36: Ja, das haben aber unglaublich viele Menschen nicht nur getan, sondern die haben gesagt,

00:04:42: ich möchte mein String gerne manipulieren, ich möchte vielleicht links und rechts ein bisschen,

00:04:45: ja, mehr oder weniger so einen Trim machen und ich möchte abhängig von welchem Zeichen da steht,

00:04:51: dann auch eine gewisse Aktion machen, was auch immer es letztendlich jetzt genau getan hat.

00:04:55: Der hat es gern published und das hatte Auswirkungen auf unglaublich viele Projekte.

00:05:01: So und dadurch, dass es dann nicht sabotiert war, sondern gar nicht mehr da war,

00:05:05: hatte es nicht zur Folge, dass die Projekte zwar installierbar und baubar waren und einen

00:05:11: komischen Side-Effekt irgendwo hatten, wenn dieser Code denn ausgeführt wurde. Das ist ja auch nicht,

00:05:15: dass man als Randbemerkung, ich sehe es ja auch nicht immer, gesagt, dass ein Framework oder ein

00:05:20: Library was dazu gezogen wird und so ein Programmcode auch wirklich immer in gleichen Teilen auch

00:05:24: verwendet wird. Es können Edge-Cases sein, ein Debug-Modus zum Beispiel, der so ein Code verwendet,

00:05:30: das würde niemals in Produktion landen. Aber der hat das unpublished, das bedeutet, jeder,

00:05:34: der npm install gemacht hat, entweder Leftpad in seinen transitiven oder in seinen direkten,

00:05:41: also in seinen direkten oder indirekten Abhängigkeiten hatte,

00:05:44: der konnte sein Projekt nicht installieren.

00:05:46: Der konnte npm install oder npm update eingeben und das Ding ist gecrashed.

00:05:52: Das war zu seiner Zeit echt fatal.

00:05:56: Aus den gleichen Gründen wie jetzt gerade eben in meinem ersten Teil

00:06:04: schon ist das meistens eng verwoben, eng irgendwo in einem Projekt mit drin

00:06:08: und man sieht nicht direkt, warum es der Fall ist.

00:06:10: Man kennt vielleicht nicht mehr exakt die Code-Stelle, wo es passiert ist.

00:06:13: Wenn es sich um so eine indirekte oder transitive Abhängigkeit handelt,

00:06:16: kennt man nicht im geringsten die Stelle, wo das verwendet wurde.

00:06:20: Und in dem vorherigen Fall war es so, habe ich schon erwähnt,

00:06:25: hat NPM nicht das erste Mal so gehandelt, wie es dann gehandelt hat.

00:06:29: In dem Fall war es jetzt so, dass nach dem großen Aufschrei und nach den

00:06:32: medienwirksamen Posts, die so um die Welt gegangen sind,

00:06:34: hat NPM die letzte funktionierende Version von den bekanntesten,

00:06:38: von diesen 250 Packages wiederhergestellt und hat dann zumindest erstmal dafür gesorgt,

00:06:44: kurzfristig, dass die Projekte, die darauf aufbauen, sich um eine Lösung des Problems

00:06:49: kümmern konnten. Was letztendlich dann bedeutet, elf Zeilen von Code selber zu schreiben oder

00:06:55: selber ins Projekt zu integrieren, wenn es jetzt nur um Leftpad ging. Ich brauche jetzt, glaube ich,

00:07:02: nicht zu fragen, ob du Leftpad auch schon benutzt hast. Ich glaube, die Antwort wird ähnlich zu

00:07:07: der anderen sein, nehme ich an. Ja, wie gesagt, wahrscheinlich schon, aber ja, dann auch wieder

00:07:13: versteckt. Vielleicht haben wir ja gleich mit dem Log4j ein bisschen mehr Glück, was die Verwendung

00:07:19: in einem Java Code damals blöd hat. Ich halte mir die Frage vergleichen nochmal auf. Ja, genau.

00:07:25: Das stellt natürlich die Frage, was für eine Reichweite kann das denn haben? Das sind jetzt

00:07:29: diese genannten untermauernden Facts, die man so hatte. Also diese Studie hat mal wirklich diesen,

00:07:35: Die Eventus-Studie hat mal diesen Ansatz gemacht und hat mal eine Analyse über diese ganzen

00:07:41: öffentlich verfügbaren Pakete gefahren und hat gesagt, welche Maintainer hängen denn

00:07:46: hinter wie viel Paketen und wie wahrscheinlich ist es denn, dass es dazu Probleme kommen kann.

00:07:51: Da haben die gesagt, dass ziemlich bekannte Packages, die es zu dem Zeitpunkt 2019 in NPM

00:07:59: gab, die reichen teilweise bis hin zu 100.000 weiteren Paketen hinein. Das heißt, es sind

00:08:07: dann nicht nur so sinnlose, ich sage jetzt mal sinnlose, aber solche kleinen unscheinbaren

00:08:13: Left-Pad-Frameworks oder -Libraries, sondern das betrifft dann tatsächlich auch wirklich

00:08:18: funktionale Sachen, wenn das Libraries sind, die mathematische Berechnungen machen in einem

00:08:21: bestimmten fachlichen Umfeld. Das erfindet auch nicht jeder neu. Und die werden dann

00:08:28: in alle Projekte mit reingezogen, weil es vielleicht auch bekannte Maintainer sind,

00:08:32: da vertrauen viele Leute drauf. Diese Pakete haben Einfluss auf bis zu 100.000 weitere Packages,

00:08:38: die groß und klein auch in einem Ökosystem gibt. Und das ist schon eine ziemlich große Hausnummer,

00:08:44: würde ich sagen. Ja, man stelle sich auch die Angriffswäche vor, die jemand, wenn er Zugang

00:08:53: zu so einem Account bekommt, dann hat zum Beispiel, wenn das der Outdoor nicht mal selber war,

00:09:01: sondern vielleicht irgendjemand, der sich mit seinen Daten eingeloggt hat, was das für Auswirkungen

00:09:05: haben kann. Genau, das sind viele Fragen, die wir uns heutzutage ja auch immer wieder stellen.

00:09:10: Gerade in so Zeiten, ich möchte das fast jetzt in diesem Podcast ungern aufmachen, aber wenn es

00:09:16: jetzt so um NSA-Themen geht, in welchen Softwarelösungen denn auch vielleicht Behörden oder offizielle

00:09:25: Stellen Einfluss haben könnten oder ihre Backdoors drin haben oder was es auch immer ist.

00:09:30: Das ist der eine Teil.

00:09:31: Der zweite Teil sind vielleicht auch wirklich Hacker oder irgendwelche Menschen, Blackheads,

00:09:36: die irgendwas Blödes oder Böses im Sinne haben.

00:09:40: Wenn die sich versuchen, in dieses Ökosystem einzubringen, was natürlich ein sehr, sehr

00:09:44: fruchtbarer Boden hier zugegebenermaßen ist auch. Das ist ein Riesenangriffsvektor. Das ist ein

00:09:50: Riesending, dass man sagt, wir haben wirklich mit einem Punkt, wo wir reinkommen, Auswirkungen auf

00:09:54: 100.000 Projekte und das kann auch tatsächlich so sein, weil NPM ja mit privilegierten Rechten

00:09:59: Sachen auf dem Dateisystem installiert. Lässt sich jetzt darüber streiten, wie man das Umfeld

00:10:04: aufbaut, wo man solche Sachen installiert, aber im ersten Moment installiert man mit NPM Fremdcode

00:10:10: auf seinem System, der gegebenenfalls sogar auch noch kompiliert wird lokal. Das heißt,

00:10:15: es wird Code ausgeführt, der von woanders kommt. Wenn sich ein Angreifer jetzt eines dieser sehr

00:10:21: bekannten Packages einheims oder wenn er sich da einschleicht und Auswirkungen erzeugen kann,

00:10:26: hat er theoretisch die Möglichkeit, auf bis zu 100.000 andere Projekte zuzugreifen und

00:10:30: seine Mailware damit zu verbreiten. Das kann natürlich auch immer noch sein, dass diese

00:10:36: anderen Frameworks da Versionen gepinnt haben, wie ich es gerade genannt habe, oder selber ein

00:10:41: Auditing machen, automatische Bildprozesse machen, sich diese Releases wirklich händisch genau

00:10:45: angeguckt haben, das selber geforkt haben und das selber so einbezogen haben. Aber in vielen Fällen

00:10:50: werden es einfach blinde Abhängigkeiten gewesen sein, die da reingezogen werden. Und das kann

00:10:55: dann wirklich verheerende Folgen haben. Und ein weiterer Fakt, den man an der Stelle noch mit

00:11:00: einbringen kann, ist, dass wenn man das jetzt mal so statistisch aufbereitet, kann man sagen,

00:11:04: wie damit verweist darauf, dass es natürlich jetzt keine top aktuellen Daten sind. Aber wenn

00:11:09: ich ein Paket über NPM installiere und habe dann diese direkte Abhängigkeit, habe ich im impliziten

00:11:14: natürlich diese ganzen anderen indirekten Abhängigkeiten und vertraue theoretisch um

00:11:21: die 80, um 80 anderen Packages oder den Autoren von ungefähr 80 weiteren Packages. Das heißt,

00:11:29: wer sich den Spaß schon mal gemacht hat und in den Node Modules Ordner, in so einem Node.js

00:11:34: Projekt reinzugucken, wenn man sich ein simples Framework reinzieht oder vielleicht auch so ein

00:11:37: Express Framework reinzieht in sein Projekt, da werden Abhängigkeiten von Abhängigkeiten von

00:11:42: Abhängigkeiten installiert und das kann wirklich so weit führen, dass man mehrere hundert MB

00:11:46: JavaScript-Wals in seinem Verzeichnis hat. Und dann fällt es auch gar nicht mehr so schwer zu

00:11:50: glauben, dass man, wenn man sich jetzt beispielsweise eines der größeren, bekannteren

00:11:56: Packages da in sein Projekt reinzieht, dass man direkt das Vertrauen 80 weiteren Packages gegenüber

00:12:03: ausspricht. Das haben wir jetzt so aufbereitet, auch nochmal in der Zahl, dass man sagt,

00:12:12: dass ungefähr 40 Maintainer in irgendeiner Abhängigkeit hinter jedem Paket steht,

00:12:20: die wir haben. Das heißt, wir haben ganz normale, durchschnittliche Libraries,

00:12:26: die haben so viele Abhängigkeiten drin, dass wenn man dann einen sogenannten Distinkt drauf

00:12:29: machen würde, dann würde man sehen, dass da 40 Maintainer drin irgendwie ihre Finger mit drin

00:12:35: hatten. Was aber auch schon aufgefallen ist und wo auch schon mal was gegengetan wurde,

00:12:40: das kann man daran sehen, dass die bekannteren Packages, die ganz oben in der Liste stehen mit

00:12:44: dem Bekanntheitsgrad, tatsächlich auch nur noch 20 Maintainer beinhalten. Da wird sich wenigstens

00:12:52: schon mal drum gekümmert. Aber 20 ist natürlich schon eine große Zahl und das entspricht ja dann

00:12:55: auch den Contributern von so einem Projekt, dass da natürlich nicht jeder bei GitHub mal ebenso

00:13:01: seinen Code anfassen kann. Das ist natürlich, glaube ich, bekannt heutzutage, dass man bei

00:13:08: GitHub nicht einfach so seinen Code reinpacet, sondern dass man einen anderen Prozess macht.

00:13:11: Sehr interessante Zahlen und ich finde das sehr gut, dass mal das ja quasi offiziell

00:13:20: man an der Studie das Ganze aufbereitet wurde, wobei, wie du schon meintest, sind die Zahlen

00:13:26: älter und ich kann mir durchaus vorstellen, dass es auch sehr, sehr schnell wächst, weil wir ja

00:13:30: immer schneller entwickeln, immer mehr Quality of Life Features haben wollen in der Entwicklung,

00:13:36: um uns dann, ja, gegebenenfalls auf das konkrete Problem fokussieren zu können und dann einfach

00:13:43: mal die nächste Library reinladen.

00:13:46: Aber es ist doch faszinierend, wie viele Abhängigkeiten

00:13:53: dort teilweise existieren und was auch so ein doch sehr kleines

00:13:58: Framework oder kleine Library für Auswirkungen haben kann.

00:14:03: Genau. Wir haben es gerade schon mal eingangs auch gesagt, dass

00:14:09: dass es Sicherheitslücken gibt in dem Fall oder dass es natürlich auch

00:14:14: Möglichkeiten gibt oder Menschen gibt, die sich diesen großen Angriffsektor

00:14:18: irgendwie auch zu Nutze machen oder sich daran zu schaffen machen.

00:14:20: Das geht aus dieser Studie.

00:14:23: Ich kann da wirklich nur, dass den Hörern hier dieses Podcast,

00:14:27: die sich dafür interessieren, mal ans Herz legen, dieses Studio auch zu lesen.

00:14:29: Da sind ziemlich viele Zahlen und Berechnungen drin,

00:14:31: die einem vielleicht jetzt ein bisschen zu viel sein werden.

00:14:33: Die habe ich auch nicht alle nachvollzogen, weil im Endeffekt

00:14:38: Ist das, was in den Boxen dazwischen steht, aufbereitet für jemanden wie mich sehr sinnvoll,

00:14:42: dass man sich das einfach mal zusammenfasst in einigen Schlagworten oder in solchen Facts zusammenfasst.

00:14:50: Wer sich dafür mehr interessiert, da wird unter anderem auch noch darüber gesprochen,

00:14:53: welche anderen Vektoren solche Packages mit sich bringen.

00:14:56: Wenn ich die noch mal einzeln jetzt erwähne, ich gehe da nicht in die Tiefe, aber es muss nicht immer nur sein,

00:15:03: den Weg, dass man das Passwort von demjenigen Maintainer von NPM rausfindet,

00:15:09: cracked oder irgendwie fischt oder was auch immer, dass man da Zugriff auf NPM

00:15:12: hat und dann seinen eigenen Code verteilt. Es gibt die Möglichkeit und das ist ja

00:15:18: letztendlich das, wo wir auf den Fakt von gerade eben mit den Maintainern

00:15:23: eines solchen Projektes oder mit Contributern von so einem Projekt eingeht.

00:15:27: Im Regelfall ist es ja so, dass man seinen Code bei GitHub als Pull Request

00:15:31: reinstellt für so ein Projekt und dann guckt das einer gegen macht. Vier Augen Prinzip, prüft das

00:15:36: Ganze, lässt das durch verschiedene Sachen, das Gans laufen, baut das mit dem Projekt, um zu gucken,

00:15:40: ob es da Schwierigkeiten gibt oder nicht. Und dann hat es diese Prüfung entweder bestanden oder

00:15:45: nicht bestanden und dann fließt dieser Code rein. Ich würde das als relativ sicher sehen, wenn ein

00:15:50: Maintainer sich da wirklich den Code intensiv anguckt, was jeder Maintainer natürlich aus

00:15:56: eigenem Interesse macht. Das heißt, an der Stelle ist schon mal eine gute Barriere. Dann haben wir

00:16:03: aber den Fall auch noch, das nennt sich Typo-Usage oder Typo-Squatting nennt sich das, ist der Fachbegriff.

00:16:14: Und zwar, es ist letztendlich nichts anderes, als dass, wenn ich mich jetzt entscheiden würde,

00:16:19: zum Beispiel Left-Pad nachzumachen, ich würde meinen Package nicht mit einem F, sondern zwei F

00:16:24: schreiben oder ich würde es nicht Pat mit D am Ende, sondern mit T schreiben oder ich würde es sogar

00:16:28: Write-Pat nennen oder Node-Pat. Ich würde einfach vorgaukeln, auch mit der ReadMe oder mit irgendwelchen

00:16:36: anderen Informationen, mit meinem Username vielleicht sogar und auch mit Beispielcode, würde ich

00:16:41: vorgaukeln, dass ich einen gewissen Sack mit meinem Package verfolge. Und dann nehme ich mir

00:16:47: ein bekanntes Framework. Ich kann jetzt auch zum Beispiel Colors.js nehmen und kann davor nochmal

00:16:51: "node colors.js" schreiben oder "node - color.js" und das könnte dann darauf hinweisen,

00:16:57: hey, das ist das "colors.js"-Framework nur für "node.js" noch mal verbessert.

00:17:01: So und das hat aber dann zur Folge, dass ich vielleicht eine direkte Kopie,

00:17:05: jetzt mache ich mich hier wahrscheinlich straffer, wenn ich den Weg erzähle,

00:17:08: wie man das machen kann, ne?

00:17:08: Erzähl mal.

00:17:12: Mal, we pretend.

00:17:15: Nein, wir nehmen mal an, irgendjemand macht das, was ich gerade eben gesagt habe.

00:17:19: Nein, dann gaukelt man das so ein bisschen vor und man würde jetzt denken an der Stelle,

00:17:24: mein Code funktioniert, weil der komplette Code ja übertragen wurde von der einen auf

00:17:28: die andere Stelle, aber jemand installiert das mit und übersieht auch noch die 5, 6,

00:17:33: 7 Zeilen, die sich irgendwo darin verstecken, die anfangen mein Dateisystem, auf dem mein

00:17:38: Code liegt, hochzuladen.

00:17:40: Das kann passieren.

00:17:42: Also es ist tatsächlich auch schon so passiert.

00:17:45: Ich meine, das wäre das Event Stream, das könnte vielleicht ein Thema für einen weiteren

00:17:48: Podcast sein. Das ist ein Framework. Das hat einen bestimmten Zweck, aber was dann passiert ist,

00:17:56: dieser Code, der da eingeschleust wurde, der guckt auf den Dateifahrt, auf den Folder-Tree,

00:18:03: den ich zur Verfügung habe, wo mein Code liegt und kann darauf zugreifen. Das heißt,

00:18:08: in meinem Projekt-Route, auf dem ich mich gerade befinde, da kann ich auf alle Codes zugreifen,

00:18:12: und zwar nicht nur auf den Code, sondern auch auf temporäre Ordner, die sich da drin befinden.

00:18:16: Und da können ja User-Daten, Fotos, Zugangsdaten, SQL-Line-Tabellen,

00:18:22: was auch immer für Daten sein, die vielleicht auch sensibel sind.

00:18:25: So, und wenn ich jetzt mein...

00:18:27: Wenn der Blackhead, der Dritte,

00:18:30: dieses Typos-Coating macht und sagt "node-color.js",

00:18:35: dann verstecken sich irgendwo da die Zeilen.

00:18:40: Ich verwende das in meinem Tool, sehe, wow, in meiner Konsole stehen viele bunte Ausgaben.

00:18:44: Das ist für mich passend. Ich kriege aber nicht im Hintergrund mit, dass dieser Code, der da eingeschleust wurde, seine Arbeit macht.

00:18:50: Das stelle ich nicht fest, weil es keine Sicherheitsmechanismen gibt, die bei Node.js abfragen.

00:18:55: Hey, NodeColors.js, das verwendet plötzlich deinen Netzwerk Traffic auf irgendeinem anderen TCP-Port oder greift auch deine Verzeichnisse zu.

00:19:05: Das sollte eigentlich eine Library, die Konsolenfarben darstellt, sollte das eigentlich nicht machen.

00:19:11: Man kennt das vielleicht vom iPhone.

00:19:13: Ich habe eine App, die plötzlich Zugriff auf meine Fotos will, aber eigentlich soll die alles andere machen,

00:19:17: außer Fotos zu greifen.

00:19:20: Solche Mechanismen, solchen Schutz gibt es dabei nicht.

00:19:25: Aber das sind so diese Angriffsvektoren, die es gibt.

00:19:29: Und dann gibt es natürlich diese malicious PRs, dass man Pull Requests macht,

00:19:33: wo was versteckt ist, was vielleicht jeder, vielleicht einer von zehn Maintainern

00:19:38: vielleicht übersieht oder man überschwemmt irgendwas mit Pull Requests.

00:19:41: und die werden versehentlich reingewunken, was auch immer es ist.

00:19:45: Das sind so bekannte Vektoren, die es gibt, um Zugriff auf so ein Paket zu kriegen

00:19:49: und die es doch häufiger gibt, als man sich so vorstellt.

00:19:51: Also auch da am besten Augen auf, genau gucken, was man referenziert.

00:19:55: Nachgucken kann ich dem Ganzen vertrauen. Wer baked das?

00:19:59: Die mache ich das am besten.

00:20:01: Was uns dann jetzt zum aktuellsten Fall oder zum fast aktuellsten Fall

00:20:07: auch ich jetzt mal in den größeren Medien bringt und zwar "Log4J". Ich glaube, als das rauskam,

00:20:14: diese Meldung, das war doch ziemlich schockierend, glaube ich. Erinnerst du dich daran,

00:20:19: dass du als erstes gelesen hast davon? Ja, das war, ich weiß gar nicht,

00:20:25: irgendein Artikel in einem technischen Online-Magazin. Und mir war selber auch gar nicht die

00:20:35: die Tragweite im ersten Moment bewusst, aber wo ich dann noch mal drüber nachgedacht hatte,

00:20:41: dachte ich mir auch so, okay, das ist ein ziemlich großes Ding, das wird sehr, sehr oft verwendet.

00:20:47: Und dann hat man es natürlich auch direkt im Firmenumfeld gemerkt.

00:20:52: Also die Räder, die sich dann alle gedreht haben, ja, das war eine sehr aufregende Zeit.

00:21:01: Wie hast du sie erlebt?

00:21:02: Ich hätte jetzt noch mal die Rückfrage gestellt, die kannst du gleich noch mal drauf eingehen.

00:21:07: In welcher Form hast du das dann im direkten beruflichen Umfeld gemerkt?

00:21:10: Ich kann kurz davon erzählen, wie es für mich war.

00:21:14: Ich habe natürlich die üblichen Quellen, die ich verfolge, wenn ich auf dem Weg zur Arbeit Podcasts höre, wie üblich.

00:21:22: Oder wenn ich abends noch mal vor dem Schlafen gehe und irgendwelche Artikel lese, die gerade per Push-Nachricht reingekommen sind.

00:21:28: Und dann kam dann "große Sicherheitslücke sorgt für Trubel".

00:21:33: Und dann denke ich mir, ja, okay, war es jetzt ein Leak wieder?

00:21:37: Wir sind doch alle nicht mehr ganz so sensibel, was das angeht,

00:21:40: weil da folgt ja irgendwie eine Nachricht auf die nächste,

00:21:42: dass es irgendwo eine Sicherheitslücke gibt oder irgendein Dienst wurde kompromittiert.

00:21:46: Schlimm genug, aber da sind wir ja mittlerweile irgendwie gar nicht mehr so sensibel,

00:21:50: weil wir den direkten Bezug zu uns nicht mehr sehen oder gar nicht mehr so.

00:21:53: Das ist jetzt sehr, sehr persönlich die Ansicht,

00:21:57: ... aber dass es in vielen Momenten gar nicht mehr so ...

00:21:59: ... schockierend ist, wie vor einigen Jahren, ...

00:22:00: ... wo dann die Meldung kam, dass irgendetwas ...

00:22:02: ... kompromittiert wurde, wo gegebenenfalls die eigenen ...

00:22:05: ... Daten bei ...

00:22:05: ... abgeflossen sein könnten. Das ist heutzutage viel zu ...

00:22:11: ... häufig der Fall und es wird halt immer darüber ...

00:22:13: ... berichtet jetzt mehr und mehr und das ist dann gar ...

00:22:15: ... nicht mehr so der Aufschrei. Deswegen war mein ...

00:22:17: ... erster Gedanke, gut, es ist ein Framework, ...

00:22:20: ... es ist eine Software, die wurde offenbar ausgehebelt ...

00:22:22: ... und wenn man dann ein bisschen tiefer buddelt, ...

00:22:25: ... und das habe ich dann getan, habe nachgeguckt, ...

00:22:26: Was ist eigentlich dieses Log4j und was ist denn diese Lücke da auch tatsächlich?

00:22:29: Das kann man ja doch recht gut nachvollziehen, noch in diesem Fall.

00:22:32: Man sieht, dass es eine Remote Code Execution sein kann, weil da wird

00:22:36: einfach blind Code ausgeführt.

00:22:38: Wenn ich sowas lese, dann fasse ich mir ordentlich einen Kopf

00:22:41: und dann im nächsten Moment tun mir die Leute leid, die das geschrieben haben,

00:22:44: weil das ist so wirklich sehr undankbarer,

00:22:47: sehr undankbarer Fall, der da eintritt.

00:22:50: Aber wie hat das denn Auswirkungen gehabt auf dich direkt?

00:22:56: Also dein Umfeld, Arbeitsumfeld vielleicht?

00:22:58: Bei mir im Bereich ist es so, dass viele Web-Services verwendet werden.

00:23:06: Also die UI und das Backend abseits von der Datenbank werden halt mittels Java zur Verfügung gestellt.

00:23:14: Und die verwenden halt das Log4j in unterschiedlichsten Versionen oder verwendeten viel mehr.

00:23:23: jetzt nicht mehr.

00:23:24: Mich persönlich hat es tatsächlich gar nicht,

00:23:27: also in meinen eigenen Arbeitsweisen

00:23:31: und Produkten, die ich benutze,

00:23:32: hat es mich jetzt nicht betroffen.

00:23:34: Beziehungsweise in einem Fall,

00:23:36: da war aber dann auch sehr schnell ein Update

00:23:38: zur Verfügung gestellt worden.

00:23:40: Das war jetzt eine Software, die ich halt selbst

00:23:42: zum Programmieren benutzt habe.

00:23:44: Tatsächlich selbst die hat Log4j benutzt

00:23:46: und die auch sehr überrascht hat.

00:23:48: Ja, die Liste ist sehr groß, ja.

00:23:50: Ja, aber das war es im Großen und Ganzen.

00:23:52: Also primär in diesen ganzen Systemen, die quasi auf meine Daten zugreifen oder zugegriffen haben,

00:24:00: die mussten dann alle abgeschottet werden.

00:24:02: Es wurden natürlich Sicherheitsmaßnahmen durchgeführt,

00:24:05: was dann aber natürlich auch im täglichen Betrieb dann erstmal ein großer Einschnitt ist.

00:24:10: Ja, das ist tatsächlich, ich habe es mir mal aufgeschrieben, also im Endeffekt klar,

00:24:17: wenn es die eigene Entwicklungsumgebung auf der eigenen Maschine ist,

00:24:21: Okay, da kann es gewisse Effekte geben, wenn jemand Zugriff auf mein System hat und einfach nur diese Execution Rights kriegen möchte.

00:24:27: Könnte es da passieren, wenn jemand Code schickt und dazu den Editor dazu bringt, das dann in privilegierter Form vielleicht auszuführen oder sowas, dann könnte es vielleicht auch Auswirkungen haben.

00:24:37: Aber wie du schon erwähnt hattest, Web Services, das ist dann der Teil, wo es wirklich brenzlig wird und wo ich bei meiner Recherche drauf gestoßen bin, ist das, was auch betroffen wurde oder betroffen war.

00:24:50: Das waren sogar die Clouddienste von Apple.

00:24:52: Da waren vereinzelte dabei, die das verwendet haben.

00:24:54: Und das ist natürlich dann ein Scheunentor.

00:24:56: Ich möchte jetzt nicht sagen, dass es komplett nach außen hin offen für alle steht

00:24:59: und man da einfach so sich das einschleusen kann.

00:25:02: Das ist jetzt nicht was, was Scriptkitties mal eben so um die Ecke bringen,

00:25:05: dass sie dann bei Apple da reinkommen.

00:25:07: Aber sobald diese Komponente,

00:25:10: wir können mal kurz auch sagen, was Log4j so auch für den Leinen gesagt, was das macht.

00:25:14: Aber wie der Name schon sagt, ist es letztendlich einfach ein Framework,

00:25:17: was fürs Logging verwendet wird.

00:25:19: Und da gibt es ja eigentlich in jeder Sprache oder in jedem Umfeld

00:25:21: gibt es ja irgendwo so ein Pendant zu.

00:25:25: Eines der bekanntesten

00:25:28: Frameworks im Java Umfeld, um ein zentralisiertes Logging durchzuführen.

00:25:32: Ich weiß nicht, ob du da noch was zufügen möchtest.

00:25:34: Du bist da wahrscheinlich durch diese Betroffene mit diesen Web Services

00:25:38: vielleicht noch mehr im Bilde, wie das funktioniert.

00:25:40: Nee, also ich denke, das beschreibt eigentlich ganz gut,

00:25:46: Aber das ist tatsächlich auch nur das.

00:25:48: Es wird halt zum Logging verwendet und bietet da ein komfortables Framework an.

00:25:54: Ja, für unsere Bubble will ich jetzt mal sagen, oder will ich es mal nennen,

00:25:59: gibt es jetzt auch bei PLSQL im Umfeld gibt es zum Beispiel auch das Logger Package,

00:26:03: welches da angezogen wird. Das referenziert man in seinem Code und hat dann die Möglichkeit,

00:26:07: solche Implementationen wie Log Levels, Verbose Output oder verschiedene Einstellungen,

00:26:14: Was das Logging betrifft, wir kennen das jetzt in der Web-Umfeld zum Beispiel, dass ich mit

00:26:18: "Console Log" mir ganz banal direkt irgendwelche Ausgaben auf die Konsole raus ausgeben kann.

00:26:22: Und dann gibt es die Möglichkeit mit Frameworks das Ganze noch ein bisschen höherwertiger

00:26:28: zu machen, indem ich mit meinen Meldungen vielleicht ein Log-Level mitgebe und dann am Ende entscheide,

00:26:32: welche Ausgaben möchte ich in welchem Moment sehen.

00:26:34: So Log4j, ganz vereinfacht gesagt, ist ein Logging Framework, was sehr, sehr viele Funktionalitäten

00:26:39: und Möglichkeiten mit sich bringt, unter anderem auch das Logs wegschicken zu einem zentralisierten

00:26:43: ... Dienst, der das dann aufgreift, diese Implementationen, ...

00:26:46: ... da profitiert man natürlich davon, dass man selbst in seinem Projekt ...

00:26:49: ... vielleicht nicht die meiste Zeit darauf verwendet, ...

00:26:50: ... um Login-Code zu schreiben, sondern dass man da natürlich ...

00:26:54: ... gerne auf so ein Framework zurückgreift, was all das schon ...

00:26:56: ... kann und das ist ein einziger Zweck.

00:26:58: Hat natürlich genau den parallelen Nachteil, den man dann ...

00:27:03: ... auch als Vorteil sehen kann.

00:27:05: Das ist ziemlich blind implementiert dann überall, das ist drin ...

00:27:08: ... und wenn so ein Fall dann öffentlich wird, dann sind ...

00:27:12: natürlich unfassbar viele direkt betroffen. Und das ist gerade bei Web-Services, wie es jetzt die

00:27:16: Cloud-Dienste von Apple sind oder wie es die Serverlandschaft von Steam, dieser Gaming-Plattform

00:27:23: betrifft oder auch Minecraft. Das sind nach außen hinzeigende Server, die möglicherweise angreifbar

00:27:30: sind. Die sind natürlich nicht mal ebenso einfach, alle offline zu nehmen und dann zu sagen, ja,

00:27:34: wir kümmern uns jetzt mal um eine Lösung. Deswegen sind alle Apple-Dienste nicht verfügbar. Das kann

00:27:39: man natürlich nicht machen. Und was sich da natürlich da anschließt, das ist ja, in

00:27:45: den meisten Unternehmensumfelden oder im meisten Unternehmensumfeld ist es so, dass bevor so

00:27:54: eine Lücke bekannt wird, oder in den meisten Fällen ist es so, ich will es jetzt ganz

00:27:58: vorsichtig mal ausdrücken, werden solche sogenannten Common Vulnerabilities and Exposures,

00:28:06: also CVEs veröffentlicht. Und das sind dann offiziell gemeldete Sicherheitslücken,

00:28:12: die sich in der Software befinden. Da werden dann hochzählende Nummern vergeben,

00:28:17: die sich auch noch in einem Nummernkreis von einem aktuellen Jahr drehen. Und da kann man

00:28:22: dann sehen, okay, es ist was gemeldet worden. Und normalerweise wird sowas auch in der

00:28:26: Responsible Disclosure gemacht. So nennt sich das. Das heißt, wenn ein Hacker irgendwas

00:28:30: findet, das kann ein Whitehead sein oder ein Greyhead, die die findende Lücke in so

00:28:36: Software, die melden die an den Hersteller dieser Software oder in dem Fall an diese

00:28:41: Open Source Gruppe. Und wenn dann in dem Fall eine gewisse Zeit, die da mitgegeben wird,

00:28:48: da will ich jetzt auch keine Aussage darüber treffen, wie groß die sein sollte oder wie groß

00:28:52: die üblicherweise ist, sagen wir einfach mal, X Tage hat ein Vendor die Möglichkeit, diese

00:28:59: Lücke zu schließen, bevor die öffentlich gemacht wird. Das ist dann, wie der Name schon sagt,

00:29:03: ... Responsible Disclosure und zwar es wird ...

00:29:06: ... offengelegt, nicht der Öffentlichkeit, sondern ...

00:29:08: ... dem Hersteller, damit er handeln kann und ...

00:29:11: ... alle und ein Update, einen Patch rausbringen ...

00:29:13: ... kann, der das vielleicht schon referenziert.

00:29:16: Und erst dann, mit einer gewissen Zeit danach, ...

00:29:18: ... wird es dann veröffentlicht, wo der Fehler war.

00:29:20: Das ist natürlich auch nicht angenehm für den ...

00:29:23: ... Hersteller, weil dann gegebenenfalls alte ...

00:29:25: ... Versionen der Software angreifbar gemacht werden ...

00:29:27: ... können oder auch Kunden, die nicht updaten, ...

00:29:31: ... was ja auch ein Teil unseres Themas heute ist.

00:29:33: die nicht updaten, dann in dem Moment, wo das veröffentlicht wird, plötzlich angreifbar gemacht werden.

00:29:39: So, und diese CVEs oder CVEs, die führen dann dazu, dass natürlich auch andere Leute sich das angucken,

00:29:47: wo denn die Lücke ist und dann exploits dafür schreiben.

00:29:50: Und in dem Moment wird es dann gefährlich, weil erst wenn ein exploit geschrieben wurde,

00:29:54: wird eine Sicherheitslücke aktiv ausgenutzt. So kann man das jetzt pauschal sagen.

00:29:58: Dann gibt es exploits, die direkt öffentlich gemacht werden und exploits, die natürlich verkauft werden

00:30:03: und exploits, die unter der Hand weitergegeben werden und exploits, die einfach nur aus Spaß

00:30:06: geschrieben werden, weil sich jemand damit profilieren möchte. So in diesem Fall jetzt

00:30:10: hier ist das aufgefallen. Es ist bekannt geworden. Es wurde nicht nur ein CWI ausgefüllt, sondern

00:30:20: Unmengen davon. Und zwar wurde das gesamte Framework auf den Kopf gestellt und es wurden

00:30:26: basierend auf den Lücken, die gefunden wurden oder basierend auf dieser einen hauptsächlichen

00:30:31: Lücke in allen möglichen Softwares, die dieses Framework verwenden, CVEs, eröffnet. Das muss man

00:30:38: sich jetzt so vorstellen. Ich gucke mir an, welche Software verwendet denn Log4j? Dann kann ich mich

00:30:45: da im Netz ein bisschen schlau machen und finde dann eine Software XYZ, eine Referenz auf Log4j,

00:30:49: und kann sagen, okay, die verwenden das derzeit, es ist noch kein Patch draußen, also wird diese

00:30:54: Software angreifbar sein. Und dadurch, dass es eine Lücke ist, die in dieser Software verfügbar

00:30:59: oder angreifbar ist, kann ich einen neuen CWI anmelden, der wird angenommen und schon hat

00:31:05: diese Software eine offiziell angemeldete Lücke. Ist natürlich jetzt wieder ein komplett anderer

00:31:10: Dunstkreis, als in dem wir uns vorhin befunden haben, aber das hat zur Folge, dass natürlich auch

00:31:15: Bug Bounty-Plattformen, wo Leute sich Geld dafür bezahlen lassen, dass sie Sicherheitslücken in

00:31:19: Software finden, überschwemmt wurden von Menschen, die diese Lücken in Software gefunden haben und

00:31:23: und gesagt haben, hey, Apple, hey, Microsoft,

00:31:25: hi, Minecraft-Hersteller, hi, Steam.

00:31:28: Ich habe bei euch eine Lücke gefunden, und zwar kann die so ausgenutzt werden.

00:31:32: Hier, gib mal bitte mein Preisgeld dafür, dass ich euch auf diese Lücke hingewiesen habe.

00:31:36: Das war ein Parallelphänomen, was man dann so feststellen konnte,

00:31:40: dass das ohne Ende passiert ist.

00:31:42: Und jetzt haben wir aber diesen einen kleinen, aber feinen Unterschied bei der Sache.

00:31:46: Hinter diesem Log4j-Framework arbeiten eine ganze Menge Entwickler oder Contributor.

00:31:52: die an diesem Framework praktisch teilhaben. Das ist jetzt gar nicht so selten, aber in

00:32:00: diesem Fall haben die Entwickler sich tatsächlich Tag und Nacht hingesetzt und unermüdlich daran

00:32:06: gearbeitet, dass sie diese Lücken gefixt haben und zwar in einem unheimlichen Tempo und das habe

00:32:11: ich mir jetzt noch mal ganz besonders markiert in meiner Aufzeichnung. Die haben das vor allem

00:32:15: einfach unbezahlt getan. Das heißt, das ist das Gegenteil von dem, was wir vorhin erfahren haben

00:32:20: hier, dass ein Maintainer oder ein Besitzer, ein Programmierer mutwillig

00:32:26: irgendetwas gemacht hat oder dass da irgendeinen Einfluss genommen wurde,

00:32:30: den Riesenauswirkungen hat, sondern es sind die Leute, die verantwortungsvoll

00:32:34: mit ihrer Software umgehen und die das allen möglichen Leuten zur Verfügung,

00:32:38: frei zur Verfügung stellen, deren Software zu verwenden.

00:32:41: Und die haben auch noch nicht mal mit der Wimper gezuckt, zu sagen, OK,

00:32:45: wir haben die Verantwortung, dass wir für die Lücke, die in unserem Framework

00:32:48: gefunden wurde, jetzt die Verantwortung tragen und wir wissen, dass jede Minute zählt.

00:32:52: Und wir arbeiten jetzt mal ganz ungeachtet dessen, wer da sponsort und was auch immer dahintersteckt.

00:32:57: Wir arbeiten jetzt Tag und Nacht daran, das Problem zu lösen und so schnell es nur irgendwie

00:33:03: geht, Patches rauszuschicken.

00:33:04: Ja genau, das war halt nicht nur dieser eine Fix, sondern es waren wirklich unzählige

00:33:08: Fixes, die danach wirklich rausgeschickt wurden oder Patches.

00:33:11: Was jetzt aber leider natürlich der Fall ist, ist, wer den Namen LockfordJ hört, ja,

00:33:18: Das Projekt hat jetzt leider natürlich so ein bisschen Schlagseite. Ich möchte es

00:33:23: nochmal betonen, diesen letzten Punkt, den ich gerade genannt habe. Die Entwickler haben

00:33:27: ihre Verantwortung, sind die nachgegangen. Und ich glaube, jeder kennt es, dass man mal

00:33:31: in der Software irgendwelche Sachen hat, die man später besser machen würde oder die

00:33:36: man anders machen würde als das mal davor. Das ist ja auch mit dem Thema von unserem

00:33:40: letzten Podcast auch einhergegangen. Man bereut seine Fehler, man arbeitet da dran und wir

00:33:47: Wir hoffen, dass so was dann nicht noch mal passiert.

00:33:50: Und Fehler mit so einer Tragweite jetzt, das greift natürlich ein bisschen auch den Stolz

00:33:54: von solchen Entwicklern an.

00:33:55: Aber die haben in der Stelle, glaube ich, einfach auch wirklich erstmal natürlich einen

00:34:00: Applaus verdient.

00:34:01: Aber naja, die sind ihrer Verantwortung nachgegangen und die haben das Problem gelöst.

00:34:09: Das Image hat wahrscheinlich ein bisschen Schaden genommen und man findet überall

00:34:13: an jeder Ecke online jetzt irgendwelche Checker, die einfach nur prüfen und Blog4j in einem

00:34:18: Projekt drin, das ist ein Pauschal sagen, da musst du auf jeden Fall gucken, weil das

00:34:20: ist angreifbar. Bis sich das von dem Schock erholt hat, wird noch ein bisschen Zeit ins

00:34:27: Land gehen. Aber auch da, um eine Parallele über all die Themen, die wir heute angesprochen

00:34:32: haben, zu ziehen. Wenn man Vertrauen einer Open-Source-Lösung oder einer Software jeglicher

00:34:39: Art Vertrauen schenkt, muss man über gewisse Dinge sich im Plan sein. Und das gehört auch dazu,

00:34:44: dass natürlich die Verantwortung da auf beiden Seiten liegt. Ich vertraue jemandem und der andere

00:34:49: weiß, dass ich ihm vertraue und weiß, was das für Folgen haben kann mit meiner Arbeit, die ich

00:34:54: tue. Und ich sollte mir jederzeit auch im Hinterkopf behalten, dass am anderen Ende jemand diese Software,

00:35:01: die ich verwende, schreibt, dass man das unterstützen kann und vielleicht auch unterstützen

00:35:06: ... sollte, wie man es auch immer schaffen kann.

00:35:08: Ob es eine monatliche Zahlung ist, ob es ...

00:35:11: ... mal den Arbeitgeber fragen ist, können wir nicht mal ...

00:35:14: ... vielleicht etwas von dem, was wir davon profitieren, ...

00:35:17: ... abgeben auch an diese Open Source Geschichte.

00:35:19: Oder ist es wirklich auf, ich will es jetzt nicht ...

00:35:21: ... unterstes Niveau nennen, sondern auf diese, ...

00:35:24: ... auf den Punkt, wo man am wenigsten Überwindung ...

00:35:26: ... brauchen sollte.

00:35:26: Es gibt Links in solchen Projekten, wo man dem ...

00:35:29: ... Entwickler einfach mal einen Kaffee kaufen kann.

00:35:30: Das wird halt genauso gemacht.

00:35:32: Hier bei mir Kaffee, klickt drauf, ich schicke ...

00:35:35: per PayPal ein paar Euro rüber und der Entwickler auf der anderen Seite fühlt das ein bisschen

00:35:38: gerecht gewertschätzt, was er gemacht hat und kann sich einen Kaffee dafür kaufen oder

00:35:44: was auch immer er dann halt gerade braucht. Das tut mir nicht weh, das tut ihm was Gutes

00:35:48: und das ist etwas, was man mit so einer enormen Reichweite wie so ein NPM Ökosystem oder

00:35:53: einem Java Ökosystem erreichen kann. Wenn jeder da so seinen kleinen Teil dafür tut,

00:35:59: dann kann man auch eine erfolgreiche Weiterentwicklung von so einem Projekt oder das Wohlbefinden

00:36:04: des Entwicklers dieses Projektes gewährleisten.

00:36:06: Und da haben wir wiederum auch alle was von.

00:36:08: Das hört sich schon fast nach einem schönen Schlusswort an.

00:36:13: Tatsächlich wollte ich aber noch einmal auch hier den Kreis zurückziehen.

00:36:17: Das Log4j Thema war ja noch letztes Jahr und das, was wir vorhin besprochen

00:36:22: hatten mit Color.js und Faker.js, das ist dann ja erst in diesem Jahr

00:36:27: aufgetreten bzw. hochgekommen.

00:36:30: Und das, was ich ganz interessant fand, war, weil ich damit letztes Jahr auch tatsächlich

00:36:37: zuerst, oder das erste Mal Kontakt hatte, war die Fragestellung für den Support und

00:36:43: für die Contribution da dran.

00:36:46: Und dann gab es ja auch sogar Diskussionen über die Projektmanager, Product Owner, wie

00:36:53: man es auch nennen möchte, darüber, wie viel Zeit die denn investieren können.

00:36:59: das wohl sehr ungünstig gelaufen ist.

00:37:01: Und da wurde dann ja sogar ein Pool für die beiden eingerichtet,

00:37:07: die das machen, die das in Teilzeit machen bzw.

00:37:11: halt eben in ihrer Freizeit und nebenher noch Vollzeitjobs haben,

00:37:16: dass die sich da auch mehr um dieses Framework kümmern können.

00:37:20: Das ist der Weg, wie es eigentlich laufen sollte.

00:37:24: Ja, jetzt habe ich gerade schon so ein schönes Schlusswort gefunden.

00:37:29: Ich glaube, wir haben wirklich viele Themen behandelt.

00:37:34: Wir haben auch echt vieles erzählt in dieser Zeit jetzt, die wir diesen Podcast geführt haben

00:37:41: oder diese zwei Folgen gemacht haben, die ja mehr oder weniger zusammenhängend sind.

00:37:44: Es sind aktuelle Themen mit vielen Fakten untermauert, die sich auch alle gerne nachlesen lassen.

00:37:50: In der Folgenbeschreibung habe ich vorher zwischendurch auch schon mal erwähnt,

00:37:53: gibt es die Links zum Nachlesen unter anderem zu Blogposings oder zu Twitter-Einträgen

00:37:58: ... oder zu GitHub Repositories, ...

00:37:59: ... aber auch zu der Studie, ...

00:38:00: ... die ich hier mehrfach erwähnt habe, ...

00:38:02: ... wo man Sachen nachlesen kann.

00:38:04: Ich glaube, das hilft vielleicht ...

00:38:06: ... oder das ist unser Ziel ...

00:38:08: ... für diese Podcast-Folge.

00:38:09: Wir möchten zum einen natürlich ...

00:38:11: ... die Augen öffnen, ...

00:38:12: ... dafür, wie man nachhaltig ...

00:38:14: ... und wie man ...

00:38:14: ... sinnvoll mit solchen Abhängigkeiten ...

00:38:17: ... in seinen Projekten umgehen kann.

00:38:18: Wie man vielleicht das Zwischenmenschliche ...

00:38:20: ... zwischen den Entwicklern ...

00:38:22: ... in der Open Source Community, ...

00:38:23: ... wie man das vielleicht auch stärken kann ...

00:38:25: ... und wie man vielleicht auch aus dem Unternehmen heraus ...

00:38:27: da Mehrwert schaffen kann, der vielleicht auch ein bisschen beidseitig stattfindet,

00:38:32: dass man da vielleicht ein bisschen mehr Rücksicht aufeinander nehmen kann.

00:38:34: Weil Open Source Entwickler sind nicht immer alleinstehende Menschen,

00:38:40: die nichts anderes tun, als kostenlos Code zu produzieren.

00:38:44: Und die müssen auch von irgendwas leben.

00:38:46: Und das sind häufig auch welche wie du und ich,

00:38:48: die in einer anderen Arbeitsumfeld, in einem normalen Arbeitsumfeld,

00:38:51: sage ich jetzt mal, ihr Tag weg tun, aber dann freiwillig in ihrer Freizeit

00:38:54: noch der Community etwas beitragen.

00:38:56: Da tut es dann umso mehr weh, wenn man sieht, was jetzt in dem ersten Thema ColorJS und

00:39:01: FakerJS passiert, wie der Entwickler davon angegangen wird oder wie das gehandhabt

00:39:07: wird, wie der behandelt wird.

00:39:09: Auf den sozialen Medien und wie man das, was er schreibt, auseinandernimmt und irgendwelche

00:39:14: Rückschlüsse zieht, dem geht es dadurch garantiert nicht besser.

00:39:16: Genauso wie es jetzt so ist, dass die Log4j-Lücke im wahrsten Sinne des Wortes eine Lücke

00:39:24: ... auch in das Image von diesem Framework gerissen hat, ...

00:39:26: ... was die Entwickler natürlich mit Sicherheit auch nicht gerne haben.

00:39:28: Genau.

00:39:31: Also, mal eine konkrete Aufforderung von mir oder von uns an euch.

00:39:36: Wenn ihr Open-Source-Projekte habt, ...

00:39:40: ... dann könnt ihr gerne mit uns in Kontakt treten ...

00:39:42: ... und auch gerne mal hier in dem Podcast darüber sprechen.

00:39:44: Das machen wir sehr gerne.

00:39:45: Je mehr Leute davon hören, ...

00:39:47: ... desto mehr Aufmerksamkeit kann das bekommen ...

00:39:50: ... und das führt letztendlich auch dahin, ...

00:39:52: ... dass man mit seinem Code auch mehr Leute erreichen kann.

00:39:54: Und zum anderen ist es so, wenn ihr in eurem ...

00:39:57: ... Unternehmensumfeld von solchen Sachen profitiert, ...

00:40:01: ... dann denkt doch mal vielleicht darüber nach, ...

00:40:02: ... ob man da vielleicht auch etwas zurückgeben kann ...

00:40:06: ... und die Arten, wie man das machen kann, ...

00:40:08: ... die haben wir ja gerade aufgezählt.

00:40:10: Auch da kann man gerne in Kontakt zu uns treten ...

00:40:13: ... oder auch über die Links, die wir in der ...

00:40:15: ... Folgenbeschreibung hinterlegt haben.

00:40:17: Einfach vielleicht selber aktiv werden.

00:40:19: Denkt mal darüber nach und in diesem Sinne denke ich, ...

00:40:21: ... glaube ich, sind wir durch für diese zwei Folgen.

00:40:24: Und ja, ich wünsche euch von meiner Seite aus ...

00:40:29: ... eine angenehme Woche und freue mich schon ...

00:40:32: ... auf das nächste Thema, auf den nächsten Podcast.

00:40:34: Und ja, überlasse gerne das Schlusswort dir, Caro.

00:40:38: Dankeschön.

00:40:40: Ja, ich also nach wie vor finde ich die Dynamik ...

00:40:45: ... und das Thema insgesamt sehr, sehr spannend.

00:40:48: Und ja, würde mich doch sehr freuen, wenn wir jemanden einladen könnten,

00:40:53: der mit uns vielleicht auch aus interner Sicht darüber sprechen kann.

00:40:58: Insofern meldet euch gerne.

00:41:00: In der Beschreibung sind unsere E-Mail-Adressen und ich wünsche euch noch einen schönen Tag.

00:41:03: [Musik]