News 48/25 –

Valdi // PHP 8.5 // OWASP Top 10 // Cloudflare

27.11.2025

// Podcast
// News 48/25

Shownotes

Die programmier.bar-Crew hat sich wieder im Studio eingefunden und bringt euch die spannendsten News der letzten Woche mit. Fabi startet mit einem Blick auf Valdi: Snapchat hat sein hauseigenes Cross-Plattform-Framework überraschend als Open Source veröffentlicht. Warum das ein großer Move ist, wofür Valdi gedacht ist und was das Framework schon kann, hört ihr bei uns.

Weiter geht’s mit PHP 8.5: Jan erklärt, welche Features im neuesten Update stecken – darunter nützliche Erweiterungen wie Pipe-Operators oder #[NoDiscard]. Außerdem erfahrt ihr, warum das Release nicht nur für PHP-Profis interessant ist. Noch mehr Hintergründe zum Release-Prozess gibt’s bald im nächsten Deep Dive. Wenn ihr dazu Fragen habt: Ab auf unseren Discord-Server!

Dave hat sich die frisch aktualisierte OWASP Top 10 vorgenommen und ordnet ein, wie sich das Lagebild seit dem letzten großen Report verändert hat und welche Sicherheitslücken heute besonders relevant sind.

Auch der große Cloudflare-Ausfall ist Thema: Garrelt hat tief in die Hintergründe geschaut und erklärt, was wirklich passiert ist, als plötzlich gefühlt das halbe Internet offline war.

Und zum Schluss wird’s noch kurios und kulturell: Wir sprechen darüber, was passieren kann, wenn sogar Profis ihre kryptografischen Schlüssel verlieren – und was die Dokumentation „Age of Audio“ für Podcast-Fans bereithält.

Download

/transkript/programmierbar/news-48-25-valdi-php-8-5-owasp-top-10-cloudflare

Jan: Hallo und herzlich willkommen zu 1 neuen News Ausgabe hier in der Programmierwahl, heute in Kalenderwoche 48 und dieses Mal ohne Störgeräusche und Latenz in der Aufnahme. Es ist ja ein Traum. Wir sprechen heute über WalDI, spricht man das WalDI aus oder
Dave: WalDI aus?
Fabi: Du kannst es aussprechen, wie Du magst.
Garrelt: Du darfst jetzt neu Coins Deutsch
Jan: Valdi. Dann heißt das ValDi. Valdi. Valdi. Valdi. Valdi. Ein, weiß ich nicht, Framework, was seit irgendwie 7 oder 8 Jahren oder so hab ich gelesen, in Production ist und immer noch mit Betalabel versehen ist und Fabi erzählt uns warum. Dann sprechen wir über PHP 8 5 und was es mit dem nächsten Deep Dive zu tun hat. Dave erzählt uns ein bisschen was über Owasp und was ihr da draußen alles falsch macht mit der Security. Alles. Und Dave erzählt und, dein Gabriel erzählt uns, warum das Internet kaputt gegangen ist. Der andere Dave. Der andere Dave. Wunderbar. Mein Name ist Jan Kryo Egbertriebel und mit mir im Studio am Start sind heute
Dave: Dave AKA David Koschitzki. Kur. Der Fabian Karel. Aber
Jan: das ist Oder hast
Dave: Du mal denn einmal mit nach nach Stift.
Jan: Einmal nach Profis.
Garrelt: Okay, Fabi, noch mal Du.
Fabi: Fabi Fink, hallo.
Garrelt: Hallo und ich bin der Fabi Fink, Garrad L krad Mock.
Jan: Oh. Gar nicht, aber ist der jetzt der einfach vollkommen verwirrt, wenn er das gehört hat so, ja.
Fabi: Ja, apropos Verwirrung, ne, Jan, das hast Du gemeint, ohne Störgeräusche. Und dann weißt Du ja, was das Störgeräusche meint, ne? Jan war verwirrt davon, dass ich unser Intro probiert hab, mit dem Klicken dieses Kugelschreibers nachzuspielen.
Dave: Kannst Du's noch mal machen, unser Intro?
Fabi: Ja. Ja,
Dave: das ist 1 zu 1. Ja. Ich hab ja gar keinen Unterschied erkannt grade.
Jan: Wenn Leute mit 'nem Kugelschreiber so rumklicken, ich muss immer an James Bond denken, so. Habt ihr Was war der erste James Bond Film, den ihr geguckt habt?
Dave: Boah, ich glaub Golden Eye, oder?
Garrelt: Ja, es
Jan: ist nämlich genau aus Golden Eye. Ja, ja, ja. Und dann hat er doch diese diese Kulibombe, so dreimal hinten drauf tippen und dann fliegt so alles die
Dave: Und der hatte doch diese Uhr, wo der so Laser rausschießen konnte, oder?
Jan: Oh, ist es nämlich. Die hab ich auch so.
Dave: Ja, krass.
Fabi: Also nächste Woche war ich Intro mit Laser.
Dave: Weil by the way Pearce Brosnan war der beste James Bond
Garrelt: Auf gar keinen Fall.
Fabi: Ja, seh ich auch
Dave: drauf jeden Fall. Hundertprozentig.
Jan: Aber ich glaub auch einfach, der beste James Bond ist immer der, mit dem Du auch großgeworden wirst.
Dave: Ja, genau. Deswegen hab ich mal verstanden, ob
Fabi: andere Leute James Bond und anderen dem man gut fanden. Peace Broson ist doch James Bond.
Dave: Ja, aber so John John Connery war auch hier, aber irgendwie es war also die sehen schon superulkig aus die alten Filme. Ich weiß Irgendwie, so Peace Broson hat so echt eine Eleganz reingebracht.
Garrelt: Wir sind ja datengetrieben. Wer hat denn die häufigsten James Bond Filme gemacht?
Dave: Oh, das sind die meisten, meinst Du?
Garrelt: Ja, die meisten sollen nicht die häufigsten, ja.
Jan: Ja.
Garrelt: Roger Moore. Roger Moore einfach. Hast nachgeguckt?
Fabi: Nee, weiß ich.
Dave: Hat sie eine Firma gemacht,
Fabi: unter anderem leben und sterben lassen, Diamanten fiebert Oktopussi.
Garrelt: Ja, weil
Dave: Oktopussi hat das
Jan: so für Anfänger. Kein Porto? Was? Dave, Du bist 'n kein Scherz Spon Profi.
Garrelt: Ich glaube, Daniel Craig war's. Der hat doch 4 oder 5 gemacht. Ja, aber
Fabi: 4. Was? Der 5. Ja. Und Roger Moore hat 7 gemacht. Ja.
Dave: 7? Ja, 7 Merz. Ich hab
Fabi: nur 3 genannt, unter anderem.
Jan: Gut, dass dass 7 mehr 5 sind, muss man vielleicht Garrel auch erzählen, wenn er halt das f und g auch erst noch lernen muss mit der Reihenfolge. Ja.
Fabi: Aber könnt ihr das Alphabet so, könnt Kopf direkt sagen, welcher Buchstabe noch was Nein, nein. Ich muss das Alphabet mit meinem Kopf aufzeigen.
Dave: Frag mich
Fabi: Fabi, fragt mich. Z vor a.
Dave: Ja. Da, glaub ich.
Jan: Was Jessi Hagen gesagt hätte.
Dave: Ja, ja, glaub ich. Z ist vor h. Nein, oh mein Gott, sag ich, ist doch egal.
Fabi: Also wir, ja, geballte Kompetenz. Vielleicht sollten wir über Tim reden, über den wir noch mehr Ahnung haben als übers Alphabet und
Garrelt: Was ist Größe 0 oder 1?
Jan: 1.
Dave: 1. So, erstes Thema, Fabi.
Jan: Erstes Thema, Fabi, erzähl doch mal was zu Waldi, Falli,
Fabi: Falli, V. Waldi, sagst Du? Nee, kann eigentlich sagen Waldi auch. Würde man, wenn man's erst mal das erste Mal hört, wird man wahrscheinlich sagen, ein, weil wir mal ein neues Cross Plattform Framework on the Block von Waldi. Und Du hast ja schon gemeint, das ist ein Framework, was eigentlich schon 8 Jahre lang in Produktion eingesetzt wird, auch in 1 sehr großen App, aber jetzt immer noch ein Betalabel hat. Und zwar wurde das in Produktion eingesetzt von der Company, die es jetzt auch Open Source hat und zwar Snapchat. Die nutzen dieses Framework haben's vor 8 Jahren entwickelt, im Endeffekt in t type Skript geschriebene Komponenten zu Native Views zu rendern und haben's jetzt eben vor ein paar Wochen Open Source und ich glaub so halt, wie gesagt, so die erste Frage, die man sich stellt, was ist denn warum jetzt und was ist denn eigentlich so der Unterschied zu React Native? Und wir hatten ja auch jetzt vor 1 Weile gab's ja auch noch mal Links von ByteDance, was ja auch released wurde, was auch ein Cross Platform Framework ist. Und ich glaube, also es gibt son paar, wenn man sich mal anschaut, also ist erst mal noch in Beta, eben weil es jetzt Open Source ist und weil es jetzt noch nicht battle testet irgendwie in anderen Apps ist, so das Framework an sich schon, aber so diese ganze Dokumentation und wie jetzt Leute das irgendwie interpretieren. Also innerhalb von Snapchat wird es sehr, sehr viel genutzt. Also Sie haben insgesamt, glaube ich, haben Sie irgendwo geschrieben, die 600000 Waldi Komponenten innerhalb von von Snapchat und haben irgendwie schon 2000000 Zeilen Typescript Code innerhalb von Snapchat geschrieben dafür. Und Darf ich mal eine
Jan: doofe Zwischenfrage stellen, Fabi? Gerne. Ach so. Ich hab mich vorgestellt, gerne. Tut mir leid. Ach so. Ja. Weil Du am Anfang so gesagt hast, das ist son eine Konkurrenz oder eine Alternative zu React Native und dann aber so in der Erklärung, es ist irgendwie da, einzelne Komponenten in 'n type Script zu bauen, muss ich mir jetzt so vorstellen, dass ich quasi in, weil die meine ganze App bauen, bootsrappen kann und nie mit Native Code in Berührung kommen oder ist es wirklich nur einzelne Komponenten von meiner bestehenden, wie auch immer anderweitig nativen App zu bauen?
Fabi: Also theoretisch sowohl als auch, also Du könntest damit auch komplett alles schreiben, aber gedacht ist es im Endeffekt so, dass Du wirklich einzelne Komponenten da hattest und dafür hattest Snapchat Snapchat geschrieben. Und das ist auch, glaub ich, son bisschen der Unterschied. So ist nicht so, dass ich jetzt sage, ich entscheide mich hier für Waldi und damit hab ich dann mein komplettes Framework, Opinated Framework irgendwelche mit drin, sondern theoretisch kann ich auch in 1 großen bestehenden Native App einfach Waldi hinzufügen und einzelne Komponenten machen. Also wenn man auch auf Snapchat schaut, sie sagen eigentlich, sie haben in jedem Snapchat Screen ist irgendeine Waldi Komponente mit drin. Es gibt auch ganze Screens, die komplett mit Waldi gemacht sind, aber das ist eben nicht nicht entschieden so. Man kann das komplett interoperabel so, man kann das einfach in seine große App mit reinziehen. Und son bisschen der Fokus und ich glaub, da ist dann der Punkt, wo sich Waldi am Ende auch von irgendwie React Native unterscheidet, ist, wir müssen noch mal 'n bisschen zurückspulen, 8 Jahre davor und Snapchat uns anschauen, so was das damals war und auch son bisschen der Fokus davon. Das ist eine supergroße App mit super supervielen Usern und die oberste Prämisse bei so etwas ist, diese Apps müssen sich komplett nach Native anfühlen, so. Und alle Performance Impects, die die's da halt irgendwie gibt, sind zahlen sich direkt auf Business KPIs aus. Und das war so die Zeit, also 8 Jahre vor 8 Jahren, das war ungefähr 2018, das war auch der Punkt, wo Snapchat die Android App einmal komplett neu geschrieben hat so. Es war 'n Zeitpunkt, wo sie irgendwie gemerkt haben, okay, sie haben's ursprünglich für iOS User gebaut, dann gemerkt, okay, die Android App kann ich mir ganz mithalten, haben den kompletten gemacht, ungefähr zu derselben Zeit. Man weiß nicht genau, was zuerst kam, ist aber auf Waldi entstanden so. Es haben sie 'n bisschen zur selben Zeit dann denke ich eingeführt. Kann auch gut sein, dass es in diesem ganzen Kontext überhaupt entwickelt wurde. Und wenn man da mal schaut, was war denn React Native, was es ja damals schon gab zu dem Zeitpunkt so und wie war es in Sachen Performance, dann war's ja schon eine Sache, die haben ja letztes Jahr 'n architektuellen, architektuelle Veränderungen angenommen in React Native gemacht. Und zwar gab's ja damals immer noch son bisschen diese JS Bridge so, wo die Kommunikation zur zur Laufzeit zwischen JavaScript und den nativen Komponenten, ich mein, beide rändern am Ende native Komponenten, was die UI angeht, aber durchaus 'n relativ hohen Overhead hatten, was zum Beispiel sich bemerkbar machte in sehr, sehr langen Listen oder so, was die irgendwie gerendert werden mussten. Dass es immer halt diese Interoperabilität zwischen JavaScript und dem Native Teil gab und diese JSBRIDGE, die sie ja jetzt auch entfernt haben, wo jetzt JavaScript ja direkt mit den jeweiligen nativen Komponenten irgendwie reden kann. Weil die hat da sozusagen immer genau diese Prämisse so, es geht immer absolut Performance und auch 'n bisschen grad dieser Websupport so. Also weil die supportet auch einige Web APIs, aber sagt auch ganz explizit so, hey, es geht darum, hier in erster Linie geht es Mobile Entwicklung und die Web ist überhaupt nicht angedacht als eine Cross Plattform als ein Cross Plattform Zielplattform oder als eine Zielplattform, sondern eigentlich nur iOS und Android. Das sind sozusagen das Mac OS auch noch. Das ist das sozusagen, was ihr ihre Zielgruppe ist. Und ich glaub, das ist auch schon am Ende so der der Hauptunterschied. Son bisschen die Frage ist, wenn's damals auch schon Reagnaive in dem heutigen Stand gegeben hätte, was jetzt irgendwie eben keine, diese Javascript Bridge nicht mehr nutzt und so, hätten sie damals auch vielleicht die gleiche Entscheidung getroffen. Wer weiß. Trotzdem gibt's jetzt heute schon noch 'n paar mehr Unterschiede als jetzt das. Ich glaub, der wirklich der größte Unterschied ist, da geht's wirklich darum, Leute wollen eine große native App bauen. Performance ist hier absolute oberste Prämisse und das am Ende irgendwie Websupporte, so was zu haben, ist gar nicht der große Punkt, sondern Cross Plattformkomponenten zu bauen, die wirklich sich sehr, sehr anfühlen so. Aber ich glaube, dass auch in dem Zuge, was Performance angeht, fast weil die noch mal mehr konkurriert mit Links von ByteDance, die ja auch megakrass auf den Performance Part gehen, mit irgendwie ihren 2 unterschiedlichen Threads, sodass UI immer Main Thread ist und viel irgendwie in einen Background Thread irgendwie ausgelagert wird und die ja sehr, sehr auf diesen Performanceaspekt gehen. Also ich tippe mal, wenn das wirklich der die die oberste Prämisse ist, muss man fast eher links mit mit Waldi irgendwie vergleichen. Aber auch Links hatten hat eine, was jetzt Plattformen angeht, viel mehr Plattformen, die targetten viel mehr Plattformen. Also ich glaube, Waldi hat schon einen sehr, sehr engen Use Case und ich glaube, grade bei sehr, sehr großen Apps, wo wirklich die Performance Einfluss auf Business KPIs hat so, da könnte es eine Option sein. Aber trotzdem muss man sich fragen, ne, so ist das jetzt was, was was wirklich genutzt wird so? Also gerade Community ist halt einfach noch überhaupt nicht existent so, wird ja auch jetzt gerade erst Open Source, hängt jetzt auch nur in 1 Company Snapchat dann doch noch mal eine ganze Ecke kleiner als jetzt irgendwie Meta. Also wenn man's auch einfach nur mal ihren Monthay Active Usern vergleicht, also ich glaub, also wenn man sich nur Facebook anschaut von Matter, da sind sie immer noch bei irgendwie in 2000000000. Ich glaub, Snapchat sind wir so bei 250 bis 300000000 Monthay Active Usern. Ist einfach eine kleinere Firma, auch die auf nicht so viele verschiedene Beine sozusagen gestellt ist. Ist die Frage, will man auf sone Technologie setzen? Aber ich mein, 8 Jahre lang jetzt schon Erfahrung, ich hab Battle testet, ist es auf jeden Fall. Und wenn das irgendwie euer Use Case ist, kann das auf jeden Fall eine Option sein. Fand ich sehr interessant. Aber warum sie auch jetzt damit Open Source gegangen sind, auch son bisschen die Frage, ne. Dafür hab ich ehrlich gesagt keine gute Erklärung.
Dave: Kurzer Fun Fact, ich hab mal nachgeschaut, Snapchat hat sogar fast 1000000000 manche Users, also 9, 9000000 ist das, was ich sogar Anfang des Jahres gefunden habe. Interessant, dass es doch größer ist. Also ich hätt das auch so eingeschätzt wie Du, aber ist gar nicht mehr so schlecht.
Fabi: Also mein mein letzter mein letzter Stand war, als wir für Snapchat auch entwickelt haben. Das ist jetzt irgendwie 3
Dave: Jahre her. Ich weiß gar
Fabi: nicht, ist das, hat sich das so verändert?
Dave: Ja, also q 1
Fabi: Ja, guck mal hier. 22 waren, also jetzt hier Statista sagt jetzt q 3 25 wären's 500000000. Ah nee, DOW, okay, vielleicht weiß ich eine DOW Zeit, die ich hatte.
Garrelt: Ich find's irgendwie spannend, dass sie nur für Snapchat sonen krasse Framework haben. Weil ich hab mich grad gefragt, Du hast 600000 Komponenten gesagt, oder? Wir machen doch nur die App Snapchat, oder? Also was ist denn da alles drin, dass Du 600000 Komponenten brauchst?
Jan: Das check ich nicht.
Fabi: Gut, ist am Ende schon. Ich meine, ich siehst ja allein allein, überleg mal, guck mal zu dem Zeitpunkt, was wir dafür entwickelt. Die haben eine komplette Games Plattform da irgendwie mit drin gehabt.
Garrelt: Klar, aber da ist ja der meiste Content kommt ja von uns so. Also ich kann mir trotzdem nicht vorstellen, wo da 600000 Komponenten sein soll.
Jan: Ich Ich
Dave: glaub ich glaub, wenn man 'n bisschen reindickt, dann findet man das schon, ne. Du hast ja auch irgendwie so sein, dann kannst Du das ja auch irgendwie noch kleiden, dann hast Du da irgendwie auch son Marketplay. Komm, wenn Du, da
Garrelt: kommst Du vielleicht auf 100 Komponenten.
Fabi: Ich nehm diesen 600000 Komponenten Ding übrigens zurück. Ich glaub, die Info hab ich mir
Dave: ausgedacht. Das
Fabi: glaub ich. Also was auf jeden Fall stimmt, waren die 2000000 Zeilen Code, die da drin haben. Sie haben 600 verschiedene, weil die Models, in denen das sozusagen, also modi, falls die aufgeteilt sind, aber ist nicht pro Komponente so. Also 2000000 Zeilen Code und 600, die sozusagen dann entweder, es gibt 3 Arten, wie dieses werden kann, so und teilweise auch zu und die, die sozusagen JavaScript oder source Code bleiben. Das sind sozusagen, die mit reinkommen. Und davon haben sie 600 Stück, die sozusagen nachgeladen werden,
Jan: weil es
Fabi: ist auch 'n bisschen Unterschied zu plane JavaScript, sodass nicht alle Module direkt beim Insialisieren geladen werden, sondern erst dann, wenn man sie benutzt. Also es funktioniert auch 'n bisschen als jetzt irgendwie eine Web Run Time von JavaScript.
Jan: Kleiner kleiner Podcasting Tipp, Fabi. Wenn Du sagst, das eine hab ich mir ausgedacht, aber die andere Zahl stimmt auf jeden Fall und da gräbst Du, glaub ich, so deine deine Glaubwürdigkeit direkt mit.
Dave: Aber es sollte mir, glaub ich, einführen. Ich werd's cool, einfach son paar Zahlen ausdenken, Iris. Immer jeder
Fabi: regt sich eine Zahl aus, am Ende muss sie son bisschen Muss
Jan: man raten?
Dave: Ja, genau. Die Aufgabe der Zuhörerschaft.
Jan: Aha. Wir löst's doch
Dave: nie auf, welche Zahl Genau. Genau. Diskutiert im Discord, welche Zahlen wir uns noch ausdenken.
Jan: Okay. Eine Zahl, die wir uns garantiert nicht ausgedacht haben, ist 8 Punkt 5, weil das ist der neue Release von der PHP. Aber seid ihr euch sicher?
Garrelt: Nächstes war 8 Punkt 4.
Dave: 8 8 Punkt 5 hab ich auch schon mal gehört. Die Zahl existiert, glaub
Fabi: ich. Die Zahl 600000 existiert auch.
Dave: Fabi, hast Du mal bis 600000 gezählt? Ich nicht so.
Fabi: Hast Du schon bis Townhope.
Dave: Jetzt hast Du mal
Garrelt: bis 8 Punkt 15. Wie zählst Du denn da?
Jan: In Punkt 5 Schritten.
Garrelt: Okay, sehr gut.
Fabi: In 8 Punkt 5 Schritten.
Jan: Ja, p 8 Punkt 5. Hier vielleicht mal 'n kleiner Spoiler. Wir machen nämlich im nächsten Deep Dive, also in der Folge die nächste Woche, glaub ich, übernächste Woche dann erscheinen müsste, machen wir ein Interview, ein Gespräch mit Volker Dusch, der Release Manager für p p 8 5 war. Und wollen da mal so was entsprechen, wie das Ganze so organisiert wird, wie das geplant wird, wie halt son doch großer Release von sonem doch sehr großen Open Source Projekt irgendwie entsteht. Und wenn ihr da noch Fragen zu habt, dann könnt ihr uns gerne vielleicht im Discord noch die ein oder andere Frage dalassen. Wir haben die Folge nämlich noch nicht aufgenommen. Wir wollten die zeitnah nach dem Release quasi aufnehmen, son bisschen auch die Gesamteindrücke von dem ganzen Prozess mitnehmen zu können. Deswegen eine seltene Chance, eine Deep Dive Frage mal loswerden zu wollen und dann können wir schauen, ob wir die Volker auch noch mitstellen können. Also wenn ihr die Folge schnell genug hört und uns schnell genug in Discord Bescheid sagt, habt ihr vielleicht da noch die Chance. Ich weiß nicht, ob Volker euch hilft, eure PHP Projekte zu debuggen, aber wenn's darum geht, was so Community Management allgemein irgendwie angeht, da kann er bestimmt bisschen was zu erzählen.
Dave: Wie geil. Man kann man kann als Zuhörer einfach dran teilnehmen. Aktiv am Deep Dive.
Jan: Geil. Aktiv am Deep Dive. Selber mitdiven. So, ja. Ja. Was hat sich dem PHP 8 5 getan? Es gibt son paar neue Funktionen und ich weiß, ihr seid ja alle hier die großen PHP Fanboys, deswegen erzähl ich euch das jetzt. Und dann könnt ihr ja mal erzählen, was ihr davon haltet so als Hardcore PHP User. Die größte Neuerung ist der Pipe Operator. Das ist son sone Pipe und dann nach rechts und da könnt ihr einfach verschiedene Funktionen hintereinander hängen, die ihr ansonsten immer so sehr, also wenn man das, ne, wenn man schon mal funktionalen Code geschrieben hat, sehr verschachtelt irgendwie sonst schreiben müsste, wenn man nicht sone Dot Notation hat. Und das macht's meiner Meinung nach 2 Sachen sehr richtig. A, hebt das unnötige Verschachtelung auf. Wenn Du quasi 3, 4, 5 Funktionen ineinander verschachtest, bist Du schon irgendwie sehr tief mit deinen Einrückungen und dein Halber Screen ist eigentlich von Whitespace nur gefüllt, bis Du irgendwie bei deinen Funktionen ankommst. Und was meiner Meinung nach noch viel wichtiger ist, es ändert die Reihenfolge im Code. Wenn ihr euch mal überlegt, wie ihr Funktionen ineinander verschachteln würdet, ja, dann ist ja die erste Funktion, die geschrieben ist, ist im Prinzip die, die zuletzt ausgeführt wird. Mhm. Und dann steht da drin quasi die nächste und die übernächste und übernächste, aber die Ausführung ist ja quasi fängt ja quasi ganz innen an in eurer Verschachtelung und baut sich dann nach außen wieder auf. So, wenn ihr den Operator Operator quasi nutzt, könnt ihr aber einfach einen Inputwert, also ein, weiß nicht, ein ein String und dann kommt der Operator Operator und dann sagt er da trimmen und dann wieder 'n Operator Operator und dann String to lower und dann wieder 'n Pipe Operator und dann String replace. Keine Ahnung, ihr könnt quasi verschiedene Operationen ausführen. Und es wird tatsächlich so ausgeführt, wie's halt im Code steht. Und das find ich, also ist halt deutlich viel besser, ja, weil es halt reduziert und man einfach Code so lesen kann, wie er ausgeführt wird und nicht quasi im Kopf parsen und revers engineinee muss, was da eigentlich passiert. Deshalb find ich das megacool.
Garrelt: Funfact, genau der ist auch als Proposal in Stage Two in Javaskibt, dieser Operator auch mit der Syntax. Find ich sehr cool, wenn der kommt.
Jan: Ja, und also was da syntaktisch noch son bisschen schwierig ist, ist, wie man jetzt einzelne Parameter in die einzelnen Stufen gibt. Da gibt es schon einen proposal für die nächste Version, was man da vielleicht auch noch machen könnte, weil das ja im Prinzip grade so ist, dass der Pipe Operator den Eingangswert aus der letzten Pipestufe im Prinzip einfach als ersten Wert in das Callable dieser Pipestufe reingibt. Und wenn Du da jetzt aber eine Funktion oder eine Methode drin hast, die den Wert eigentlich an zweiter oder dritter Stelle brauchen würde, musst Du da noch 'n bisschen Syntax Sugar drum rum betreiben, eine anonyme Funktion oder so was zum Rappen nehmen. Und das im Prinzip 'n bisschen gezielter positionieren zu können, das ist da son Feature, was da vielleicht im nächsten Schritt noch noch kommen soll. Fänd ich auch megacool, weil es halt noch mal mehr unbedingt Boilerblade Code sparen würde dann.
Fabi: Okay, kurze Frage für eure Ihr seid seid jetzt doch alle auf deutschem Keyboard, oder? Mhm. Wie macht ihr 'n Pip Operator auf deutschem Keyboard? Wo
Dave: liegt ihr denn? 7, shift, unten.
Jan: Was? Na ja, einfach nur einfach nur 7, ne? Oh. Also für die Mac Leute.
Dave: Sorry, ich mein mein ich. 7 und shift und dann dieses über. Das aufm Mac.
Garrelt: Ich find mir,
Jan: ich find's mir
Dave: jetzt einfach, irgendwas
Garrelt: irgendwelche. Die
Dave: Sache aber die
Jan: Wirtschaft Apfel
Dave: Apfelka. Apfel, der
Fabi: war nicht klar. Jan, Du hättest es aus mf f gewusst, wo Du 'n Pep Operator machst.
Dave: Ja. Hey, wieso? Ich hab's doch gesagt. Ich hab irgendwelche gemacht. Ich hab Jochen verstanden, was Du gesagt. Aber also
Jan: Fabi, das ist ja auch son bisschen sone Coding Frage, ne? Das ist ja so im Muscle Memory irgendwie drin. Und das dann quasi in Wort zu bringen, ist wahrscheinlich schwierig. Also ich hätt ich musste auch das einmal tippen und draufgucken, um's dir sagen zu können, aber ich konnte ihn zumindest direkt tippen so, ja? Also jeder, der irgendwie einigermaßen komplexe if statements schreibt, hat den er schon mal benutzt, also dass er jetzt nicht so exotischer Charakter irgendwie.
Fabi: Wohl wahr.
Garrelt: Aber Fabiovious Flag, Du nutzt doch auch Englische, oder?
Fabi: Ich nutze ich nutz das Englische, nicht das Deutsche, ja.
Jan: Ja, ja, genau. Aber ich benutz ja auch das Deutsche und das
Fabi: Ich hab's wieder vergessen, wo's das Deutsche ist. Ich hab mich grade gefragt, so liegt es an 'nem sehr komplexen Platz aufm Deutschen
Garrelt: Ja, genauso wie die geschweiften Klammern find ich auch komplex, weil.
Fabi: Okay, könnte es machen. Danke.
Jan: Danke. Also Dave nicht, ja.
Garrelt: Dave weiß es nicht.
Dave: Was? Ich hab's richtig gemacht. Ich
Garrelt: hab's aber,
Dave: Ich hab Option 7 und dann. Weil das ist ja das ist ja dieser Strich zusammen mit diesen Größen. Ach,
Fabi: Du willst beides. Ich wollte aber nur den Pipe Operator. Ich wollte
Dave: das ging nur sorry, okay,
Garrelt: das musste ich
Jan: machen. Dann war das am
Dave: Genau. Alle, die ich kenne. Alle alle 3, die ich kenne.
Jan: Command Option Shift. Irgendwas wird schon passieren. Den Buchstaben hab
Fabi: ich auch
Dave: schon mal gehört.
Jan: So. Dann eine andere Erinnerung und da da würd mich interessieren, was ihr davon haltet, ist eine Annotation für Funktionen, die da heißt No descart und was das taugen soll, ist, es soll dich dazu zwingen, den Rückgabewert dieser Funktion zu nutzen und nicht verfallen zu lassen. Also wenn ich jetzt eine Funktion hab und ich schreib da als Annotation not iscart dran und ich nutz die irgendwo in meinem Code, ohne den Returnwert mal zumindest in eine andere Variable zu schreiben oder in eine anderen Funktion weiterzuverwenden, dann kriege ich quasi eine Compilerwarnung, weil offensichtlich hier ein ein wichtiges Ergebnis nicht genutzt wurde oder so. Oder vielleicht ein sehr teures Ergebnis nicht genutzt wurde. Also wie man das ja nutzt, ne, sei noch mal dahingestellt. Aber was haltet ihr von sonem Sprachfeature? Ich hab das ehrlicherweise noch nirgends woanders so gesehen.
Garrelt: Grundsätzlich interessant, weil ich glaub, da geht's eher darum, besseren zu schreiben. Also ich glaube, es geht darum, dass man dann sagt, okay, wenn Du diese Funktion aufrufst, aber den Return, weil Du nicht nutzt, dann hast Du irgendwie die Intention dieser Funktion nicht richtig genutzt. Und das find ich eigentlich interessant erst mal. Ich wüsste nicht, ob das cool oder nervig ist, weil kommt wahrscheinlich darauf an, wie Du damit umgehen möchtest. Wär für mich jetzt intuitiv eher kein Sprachfeature gewesen, sondern eher 'n Frameworksache oder was auch immer. Also, aber ist immer interessant, also
Fabi: Aber gefühlt sind doch ihre ganzen Beispiele eigentlich nur so, hey, Du gibst 'n Array rein und gibt, gib auch 'n Array zurück und dann würdest Du's ja, falls Du's nicht benutzt, eigentlich nur den Punkt haben, dass Du die Funktion falsch verstanden hast und einfach nicht, also denkst Du sozusagen, das Array wird verändert, kriegst aber 'n Neues zurück so. Und ja, find ich auf jeden Fall gut, wenn die Sprache mir Bescheid sagt, hey, Du hast die Funktion nicht verstanden so.
Garrelt: Ja, da
Fabi: Aber höchstwahrscheinlich würde, also andere These ist, wenn ich's ausführe, würd ich wahrscheinlich relativ auch auch merken, dass ich's nicht ganz richtig verstanden habe, weil
Dave: wenn ich am Ende, weiß nicht.
Garrelt: Aber ist einfacher zu finden. Also Ja, genau. Ist schon immer deutlich einfacher dann mit so sprechenden Fehlern so was zu finden. Also schönes Buch.
Jan: Und Du kannst es auch mit 'nem mit 'nem kannst Du auch quasi im Code annotieren, zu sagen, ist mir bewusst, dass ich das hier nicht nutze, ist aber an dieser Stelle okay. Das geht dann, glaub ich, wieder so auf auf Garwitz Motiv zurück. Es forciert dich halt son bisschen darüber nachzudenken. Ist es hier sehr bewusst, dass Du das dropst? Dann kannst Du's auch im Code so bewusst highlighten und dann ist es ja wieder okay. Aber Du musst zumindest einmal drüber nachgedacht haben. Ja. Aber der Punkt von Fabi ist natürlich auch richtig. Wenn Du dir denkst, es gibt keine keinen Returnwert, weil Du das irgendwie als Referenz reingepasst hast und dann in deinem Array rumschreibt oder so, ja. Kann kann auch sein.
Fabi: Ja, ist, glaub ich, ganz nett, aber ja.
Garrelt: Nice to have.
Jan: Ja. Dann gab's noch son paar kleinere Sachen, die müssen wir jetzt, glaub ich, nicht alle im einzelnen Detail durchgehen. Es gibt 'n neues URL Pasing, endlich mal objektorientiert und nicht mehr nur mit komischen Arrays, die durch die Gegend geworfen werden. Und der größte Running Gag in PHP überhaupt ist, wie schlecht das mit Arrays umgeht und diese ganzen Helper Methoden, die es für Arrays hat oder nicht hat. Es gibt jetzt endlich eine Array first und Array last Methode. Mit so. Ja, ja. Also PHP ist da jetzt auch irgendwie in den Neunzigern angekommen.
Garrelt: Na ja, Jource gibt's halt immer noch nicht. Ja? Nicht von Horst,
Jan: das stimmt oder? Stimmt, ne. Also genau, in in einem der letzten großen Releases kamen ja so R A Key First und R A Key last dazu, aber irgendwie, dass man auch an die Objekte will, haben sie vergessen und haben gedacht, na ja, wenn Du das Erste haben willst, dann holst Du dir R A Key First und greifst dann damit auf den Eintrag zu. Da gibt's jetzt im Prinzip noch son paar kleine Helper. Ja, und noch 'n paar kleine andere Sachen. Cloning wurde verbessert, Closures wurden verbessert. Und was vielleicht ganz cool ist, es gab, ich glaub, mit 8 3 oder so eingeführt oder 8 4 eine Annotation für Override, wo Du bei 'ner Funktion in der Klasse sagen könntest, okay, diese Funktion überschreib bewusst eine Funktion in ihrer Parentklasse. Und wenn sich dann der Name geändert hat und das quasi keine Funktion mehr zum Überschreiben gehabt, dann hast Du halt auch eine Compiler Warnung gekriegt, weil dein sehr bewusstes Overrite quasi kein Overrite mehr war an der Stelle. Und das funktioniert jetzt auch mit Properties. Ich hab das ehrlicherweise noch nicht benutzt, aber das ist, glaub ich, auch sone Geschmacksfrage Richtung Komposition oder Inharitance, aber für die Leute, die halt viel mit Inharitance machen, kann es glaub ich super superhilfreich sein und insbesondere für Leute, die halt in Frameworks rumschreiben, penden, extenten und so weiter. Da ist halt super hilfreich zu wissen, okay, die Methode, die ich hier überschreiben wollte, gibt's die noch? Hat ihren Namen geändert et cetera et cetera? Und wenn dir da der Compiler helfen kann, dann ist das, glaub ich, schon irgendwie immer was wert. Ja, das vielleicht nur ganz kurz zu PHP 8 5, bevor wir dann da nächste Woche noch mal 'n bisschen über den Release Prozess sprechen können. Spannend. Spannend. Spannend bleibt's auch beim Dave. Dave, was macht das Internet alles falsch, wenn's
Dave: Security geht? Alles. Alles. Alles ist Also ist ja
Jan: alles beim Alten geblieben, eigentlich.
Dave: Ja, genau. So und Gerald, letztes Thema. Nein, genau. Ich rede hier über die OWAST Top Ten Liste. Kurze Erklärung, was das überhaupt ist. OWAST ist ein Akronym und steht für. Und was ist eine Top Ten Liste? Ihr könnt's euch vielleicht denken. Es ist Aber
Jan: sind es wirklich 10 oder hast Du dir das ausgedacht?
Dave: Nein, es sind wirklich 10. Nein. Es ist wirklich 10. Es ist nämlich eine Top Ten Liste und identifiziert quasi so die 10 kritischsten Security Risiken Risiken. Für Webapplications. Oh komm, wir machen's auf Englisch einfach. Genau. Und das sieht primär so als Awareness Dokument, ne. Also einfach so, hey, guck mal, wir haben das so analysiert, sehr viele Open Source Projekte, sehr viele Security Profis, die drüber geschaut haben und gesagt, hey, das sind wirklich die kritischsten Issues, die grade total prominent sind. Hier wisst ihr Bescheid, habt da so einfach 'n bisschen Awareness geschaffen. Und das genießt halt 'n hohen Grad an Anerkennung, weil da halt eben superviele Projekte dabei sind, die Experten, die das dann bewerten. Und das wird alle 4 Jahre geupdatet. Deswegen Funfact, wir hatten nämlich in der News 47 21, also vor 4 Jahren auch schon mal drüber gesprochen. Könnt ihr euch noch dran erinnern, wer das vielleicht war?
Garrelt: Wer Dennis gesprochen hat?
Dave: Nee, Dennis war's nicht.
Garrelt: Dave, oder?
Fabi: Dave hat er noch gar nicht.
Dave: Da war ich noch nicht da auf der
Garrelt: Welt. Als Special guess. Nee.
Dave: Aber Es war einfach, nee, auch die Fahrt. Jo, ich hab aber 'n paar Jo. Ja, Jojo.
Jan: Hey. Jojo.
Garrelt: Ja, schaut uns an Jojo.
Jan: Schau doch
Dave: an Jojo, ganz viel Liebe gehen raus. Genau, der hat darüber schon gesprochen. Also falls ihr da noch mal wissen wollt, was da vor 4 Jahren abging.
Fabi: Die Folge vor 4 Jahren.
Dave: Genau. Ja, ich muss son bisschen kommen Die News Folge, jetzt
Jan: heißt es ja nicht mal so die, das hab sone News Folge. Ja. Beste Halbwertszeit immer, sone News Folge.
Dave: Ja, aber das ist aber das ist aber interessant, weil nämlich bei dieser Top Ten Liste hat sich dieses Jahr nicht so viel getan tatsächlich. Also Und
Garrelt: weißt Du letztes Mal oder so?
Dave: Im Vergleich zu der, Frau
Garrelt: 4 Jahre.
Fabi: 4 Jahre, ich würde nur alle, die wird ja
Jan: nicht jedes Jahr gemacht.
Dave: Genau, so ungefähr alle 4 Jahre wird das dann halt immer aktualisiert und tatsächlich kamen 2 neue Dinge hinzu und sonst hat sich da einfach eigentlich sehr viel
Garrelt: Dann können wir doch jetzt eigentlich sehr viel Dann können wir doch jetzt am Hingigst den Teil von Jojo einfach wieder hier reinschneiden und dann.
Dave: Genau, jetzt können wir einfach den Teil von Juli reinschneiden. Nee, aber vielleicht noch mal die, die die Folge nicht gehört haben, muss auch nicht wollen. Kurz noch mal, wie diese Top Ten eigentlich entsteht, weil es eigentlich interessanter wird, nämlich sone Formel genommen und aus verschiedenen Faktoren ermittelt. Also wie häufig tritt diese Schwachstelle auf? Wie einfach kann das ausgenutzt werden? Und natürlich, wie groß ist der Schaden potenziell dabei entstehen kann?
Garrelt: 2 Euro.
Dave: 2 Euro, genau. Das ist Maximum. Genau und da kann man sich da so die einzelnen Punkte anschauen aus dieser Top Ten Liste. Ich find das eine sehr coole Übersicht, also lohnt sich auf jeden Fall mal da drauf zu schauen, weil da sind zum Beispiel so was wie Backgroundinformationen dazu. Also wie wurde es dieses Issu die Jahre davor bewertet? Wie lang hat man das unter Beobachtungen gehabt? Was sagen umfragewerte der Community? Dann hat man diese Score Tabelle halt auch noch dazu. Da wird diese Schwachstelle ziemlich gut beschrieben dann auch, ne. Also was sind so typische Auswirkungen? Wann ist man beispielsweise besonders gefährdet in welchen Projekten? Und natürlich ganz wichtig steht da auch so, wie kann man verhindern, davon betroffen zu sein? Und geben dann auch so paar Beispiele für Angriffsszenarien, also eigentlich sehr, sehr cool aufgearbeitet. Und wie bereits angekündigt, es hat sich nicht so viel getan in den letzten 4 Jahren, aber ich würd trotzdem gern noch mal paar Dinge erwähnen, denn es kamen 2 neue Dinge dazu und das Erste, was neu dazu kam und direkt auf Platz 3 gelandet ist. Könnt ihr euch denken? Das war sehr prominent die letzten Wochen und Monate.
Garrelt: Injektion.
Dave: Das ist nicht korrekt, aber ist auch dabei.
Fabi: Ich hab die Liste vor mir, ich rate nicht rein.
Dave: Ach so, auch Mist, ist halt erst okay.
Garrelt: Warte mal, das ist der Bericht von sonst 21.
Dave: Na ja, wir haben auch sehr häufig in den News drüber gesprochen. Es sind natürlich die Software supply Chain Failias sehr prominent dieses Jahr, sehr dominant auch. Ich glaub, niemand kam da drumherum davon nicht zu hören und wurde sogar auch von der Community Umfrage dann auch direkt von 50 Prozent auf Platz 1 gepackt. Der hat gesagt, okay, ja, das aber so krass, das ist 1 der größten Failias und weil's halt diese Aktualität hat in diesem Jahr Wird das? Auf Platz 3 gerutscht.
Garrelt: 20 21 war das gar nicht in den Top Ten
Dave: oder? Nee, da war's gar nicht drin. Deswegen kam wirklich neu und zack direkt auf die auf den dritten Platz. Apropos Siegertreppchen, da können wir auch direkt weitermachen. Ganz interessant, auf Platz 2 ist sogar hochgerutscht von Platz 5. Auf Platz 2 ist Security. Vor allem also ist ist sehr dominant geworden auch dieses Jahr und vor allem schade, weil's eigentlich häufig ein einfacher vermeidbarer Fehler ist. Geht halt darum, wenn irgendwas im System der App oder halt irgendwie Cloud Services, vor allem Cloud Services, irgendwas falsch konfiguriert sind. Da hatten wir sogar auch, ich es kommt wieder eine weitere Cross Referenz, dieses Jahr drüber geredet, in der News 32 25, da ging's diese T-App. Da wurden nämlich diese Cloud Services falsch eingerichtet, da der Firebase Storage, den man einfach einsehen konnte und die Endpunkte, die einfach public waren und da keine Überprüfung war, wer darauf zugreifen konnte. Und da wurden ja sehr viele Daten von sehr vielen Frauen geleakt, was genau das Gegenteil dieser App war.
Garrelt: Ach, die wohl Ja.
Dave: Ja, genau. Das war auch son Ding. Und auf Platz 1, das ist natürlich sehr spannend, zweites Jahr in Folge, broken Access Control. Das ist immer, wenn irgendwas bei der Überprüfung nicht klappt, welcher User genau was machen darf, ne. Also ganz simples Beispiel, ich kann als User irgend eine URL aufrufen von der Adminseite und da wird nicht überprüft, ob ich überhaupt Admin bin oder nicht. Wirkt wie 'n einfacher Fehler, aber ist immer noch sehr stark vorhanden. Sehr viele Projekte haben dieses Problem und diese Schwachstelle kommt tatsächlich in sehr vielen Projekten am häufigsten vor. Hätt ich so nicht gedacht, aber ist tatsächlich immer noch weiter dominant. Genau. Ja, ansonsten Liste, ohne da genau drauf einzugehen, aber sehr viele auch kryptografische Probleme, also Leute benutzen schwache Verschlüsselungsalgorithmen wie den DES oder auch irgendwie veraltete Hash Funktion wie den m d 5. Injection, wie Du gesagt hast, Cari, ist auch weiterhin dabei. Fehlendes Logging, Monitoring, Alerting, das sind auch alles Dinge in dieser Top Ten Liste. Also ist auf jeden Fall sehr spannend, sich die mal alle anzuschauen, weil man grad son sehr gutes Gefühl dafür bekommt, was ist grade präsent? Was sind häufige Fehler? Und ich würd sagen, man setzt sich einfach mal so grundlegend mit so Security aufeinander. Ist auf jeden Fall sehr, sehr cool, sollte jeder mal reingeschaut haben.
Garrelt: Der Fehler heißt ja auf Deutsch Fehler bei der Zukunftskontrolle? Ja. Und weißt Du, wer auch Fehler bei der Änderung der Zukunftskontrolle gemacht hat?
Dave: Cloudflare. Cloudflare.
Fabi: Leider hat's den Übergang
Jan: Aber es, wenn ihr noch Fragen habt zu dürfen, könnt ihr das auch jetzt auch machen. Okay,
Garrelt: kein Frank.
Jan: Du kannst nicht son guten Übergang machen und dann sagen, aber wenn ihr noch über das andere Thema
Dave: nur Ja, wir können doch noch mal rüber bleiben.
Garrelt: Ich wollte deinen Platz als bessere Übergangsmacher nicht einnehmen, Jan, deswegen wollt ich's dir noch mal selbst crashen.
Dave: Aber das ist aber krass, weil eigentlich hast Du Jan direkt vom Thron verstoßen so. Es war ein Übergang und der war viel besser als, wir hatten jemals gesagt.
Jan: Das war crazy. Let's go.
Garrelt: Ja, erst mal vielen Dank, Dave.
Dave: Gerne.
Garrelt: Wir machen bestimmt auch solche Fehler. Aber bei uns ist das nicht so schlimm, weil wenn wir das machen, liegt nicht das halbe Internet wieder lahm. Cloudflare hat wieder 'n Bock geschossen.
Jan: Richard, falls Du jetzt zuhörst da draußen, ignorier alles, was Karel grade gesagt hat.
Garrelt: Ich arbeite nicht bei Lotung. Ja, genau. Ich glaub, der hat wieder 'n Bock geschossen. Am achtzehnten November lag wieder so ungefähr das halbe Internet lahm. Und es lag am Ende an 1 Änderung, die Sie gemacht haben, an Zukunftsrechten in 1 Datenbank. Und ich versuch da, also ich find das Thema aus verschiedenen Perspektiven sehr, sehr spannend. Ich versuch mal ganz kurz mündlich abzukleppern, was da passiert ist. Und zwar haben sie ein Datenbanksystem, was distributed ist. Also es gibt viele verschiedene Server, auf die dann die weitergeleitet wird. Dann werden die Daten geholt und zusammengeführt und an den praktisch Verbraucher gegeben. Und da war die Zukunftskontrolle son bisschen, weil die Anfrage wurde mit einem speziellen User gemacht, aber die Anfrage an die einzelnen Server wurde dann immer mit einem Account sozusagen gemacht. Das heißt, am Ende hatte eigentlich der User eine eine Standard Access Rights, obwohl vielleicht der eigentliche User 'n bisschen eingeschränkter war. Und das haben, wollten sie eben verbessern und haben gesagt, okay, wir versuchen jetzt dieses System zu ändern, sodass es fein granularer wird. Das hat aber dazu geführt, dass User dann in ihren Anfragen, die sie gemacht haben, wo nicht überprüft wurde, welche Datenbank sie eigentlich anfragen wurde, andere Rückgabewerte zurückkamen. Also da wurden dann Tabellen zurückgegeben, die vorher einfach nicht da waren als Zugesrecht, zumindest was die Metadaten angeht. Das hat auf jeden Fall am Ende dazu geführt, dass die Rückgabewerte anders waren. Und am Ende wurde dadurch eine Konfigurationsdatei mit doppelten Einträgen beschrieben, die dann automatisch alle 5 Minuten erstellt wird, Distributed wird an das ganze System sehr, sehr schnell. Und das dazu geführt hat, dass ein Service, der die ausliest, aber ein Limit gesetzt hat, wie groß die sein darf, einfach fehlgeschlagen ist. Und das war ein Bot Management Service, der also guckt, okay, ist die Anfrage von 'nem Bot. Und der schlug dann fehl. Und das aber so essenziell, dass dann ja, einfach praktisch das halbe Internet oder ihren der Service von ihnen, der einfach die ganzen Anfragen bearbeitet, kaputt war. Und genau, erst mal interessant, dass es auch wieder son Zukunftskontrollrechte Ding ist und es auch wieder eine Änderung von ihnen war, die dazu geführt hat, dass kaputt war. Was auch sehr, sehr spannend war, ist, dass sie anfangs dachten, das wär 'n Angriff von 'nem Botnetz, weil einen Tag vorher hat Azure einen der größten DDoS Attacken überhaupt verhindert mit 1, wie sagt man das so, Anfragegeschwindigkeit von 15 Terrabit pro Sekunde von einem Bordnetz. Also 'n riesiges Netz und dann dachten die so, oh fuck, das ist dieses Netz, dass da was probiert, vor allen Dingen, weil sie so Spikes hatten in ihren Ausfällen. Und es sich erst später herausgestellt, okay, nee, das ist relativ stabil. Und sie hatten das erst falsch eingeschätzt, haben dann irgendwann gemerkt, okay, fuck, das ist dieses Problem konnten's relativ schnell fixen, indem sie einfach diese Datei, eine bessere Version davon ausgerollt haben, die eben nicht fehlerhaft war. Und dann hat's natürlich, und das find ich auch immer spannend, bei diesen riesigen Services dauert das immer, bis es sich wieder erholt, weil dann so viele Anfragen nachkommen, dass die Services dann erst mal überlastet sind so. Und dann musst Du's scalen und so. Das dauert dann alles echt immer ziemlich lang. Aber sie haben's am Ende wieder gefixt bekommen. Was dann aber auch superspannend ist, sie haben echt 'n sehr, sehr ausführlichen Bericht auf ihrem Blogartikel geteilt. Und Jan, vielen Dank für diesen Post über x, wo der Chef von Cloudflare erzählt hat, wie das so zustande gekommen ist. Weil es ist ja schon sehr ungewöhnlich, dass so ein ausführlicher Pol, also Blogpost über diesen dieses Problem mit Codestellen, mit Infrastruktur, also wirklich sehr, sehr detailliert auch zu sonem Fehler veröffentlicht wird. Und das ist sehr, sehr spannend, dass sie da als Sogroßunternehmen trotzdem so flexibel und auch transparent sind, dass sie so was einfach machen und auch machen können. Das fand ich auch superspannend. Also ich weiß nicht, ob wir den verlinken können, aber das, der hat praktisch auf Hacker News 'n bisschen erklärt, wie das zustande gekommen. Ist irgendwie 'n sehr, sehr interessanter.
Jan: Und auch fand ich persönlich irgendwie super Voll. Also charmant und so, wie Sie da so beschreiben so, ja. Wir haben uns da alle zusammengeschlossen im Prinzip, ja. Also dafür, dass Cloudfair sone Riesenbude ist, ja, hätte man nicht gedacht, dass sie bis zu der Ebene hoch irgendwie noch so arbeiten dann.
Garrelt: Mhm. Ja, voll. Ist wirklich sehr, sehr schön erzählt. Aber am Ende find ich's, und das ist eigentlich immer das Spannendste dran, ich find's so krass, dass dass das Internet mittlerweile sonen Bottleneck auch hat. Also so viele wichtige Services, die dann einfach, weil Cloudfeller so ein eine Änderung macht, einfach erst mal kaputt sind eine Zeit lang, ne. Also das find ich, ist auch grade eine sehr, sehr spannendes State des Internets, dass da so alles über oder vieles über Cloudflake. Das Und
Dave: 'n paar Wochen davor ja auch der AWS ausfallen, ne.
Garrelt: Ja, was wir Wochen ähnlich, ja.
Dave: Sehr, sehr krass war im Impact.
Jan: Es kam ausm Nähkästchen plaudern. Ich war mal in 'nem Technical Audit drin und hab da sehr stolz erzählt, wie wir unsere Infrastruktur irgendwie in kürzester Zeit von AWS wegportieren könnten zu irgend 'nem anderen Cloud Anbieter und wir sind da überhaupt nicht abhängig und bla. Und der Auditor meinte dann nur so, ja, aber man muss ja ganz ehrlich sein, wenn AWS 'n Problem hat und sich grade verabschiedet, dann interessiert sich auch niemand mehr für deine für deine Plattform, für dein Produkt, weil das halbe Internet halt eben mit weg ist. Ja. So, ja? Und das ist ja bei bei Cloudflare ähnlich so. Ja, Du kannst dich versuchen davon unabhängig zu machen. Es hilft dir aber halt im Zweifelsfall nicht, weil deine Kunden, deine User, dein whatever wahrscheinlich nicht mehr zu dir kommt, weil Cloudflare hüll 'n anderen Teil des Internets mit runtergerissen hat, so, ja? Das ist auch krass, wenn man sich das mal so vorstellt.
Garrelt: Voll und es ist halt, ich find's fragwürdig so, ob man wirklich so viel Kontrolle diesen einzelnen Firmen überlassen will. Also ist es so gut, dass sich sich alles so konzentriert auf diese einzelnen Firmen, weil
Jan: Na ja, aber das ist ja, also das ist ja son Henne Ei Problem, ne. Also Ja. Die haben das ja sich nicht genommen, sondern die Kunden sind, also die Kunden sind ja freiwillig zu denen gekommen. So, und jetzt haben die halt diese quasi Monopol- oder Oligopolstellung mit AWS und mit Google und so allen zusammen. Und was willst Du halt machen? Weil wie gesagt, selbst wenn Du jetzt woanders hingehst, sie reißen ja trotzdem das Internet für dich mit runter.
Garrelt: Ja. Klar. Aber es ist irgendwie, also so zu denken, ja okay, da konzentriert sich so viel an diesen Stellen.
Jan: Ja, also wenn man Insbesondere wenn man halt überlegt, dass die Kundenidee, das Internets ja eigentlich son dezentrales Netzwerk ist und ja genauso irgendwie IP und TCP funktioniert, ja, und jetzt sagen wir so, ja, das mit diesem dezentral ist doch irgendwie gar nicht so wichtig. Wir machen uns hier son Single Point of Failor irgendwie ins Netzwerk und wenn der umkippt, kippt halt irgendwie alles andere mit Ja. Das ist halt schade so.
Garrelt: Ja. Aber trotzdem cool, wie transparent Sie waren. Ja. Ist echt 'n cooler Blogpost. Ich glaube, es lohnt sich, denen auch jetzt trotzdem noch mal zu lesen. Sie haben da auch tatsächlich so Rustcode von der spezifischen Stelle von dem Service geteilt. Kann kein Rost, aber Unrap. Unrap, richtig.
Dave: Unrap, ich seh's grade.
Garrelt: Geil. Lustig, weil der CEO sich während dieser Zeit 'n Burrito anrappt hat.
Jan: Also na ja, okay. Ja. Gareth hat vorhin sone super Überleitung weg von Dave gemacht, aber glaub, Dave war noch gar nicht fertig. Dave hatte noch eine andere Single Point of Fager Geschichte irgendwie mit am Start. Also müssen wir doch noch mal zurückziehen.
Dave: Ja, aber genau, also sehr gerne, aber ich glaub, das ist son passender, lustiger Schmankerl am Ende. Von daher eigentlich ganz okay in der Reihenfolge. Es gab doch mal diese Kategorie so das Malheur der Woche oder so, oder?
Garrelt: Ja, die
Dave: irgend In
Fabi: irgend 'nem anderen Podcast.
Dave: In irgend 'nem anderen Podcast. Aber ich dacht mir so, das das nehmen wir's aber für uns so irgendwie.
Jan: Diese Kategorie hat Dave sich grade ausgedacht.
Dave: Mein ich doch, mein ich doch, Malheur. Es ist ein Riesen Fauxpas passiert. Und zwar ist es son bisschen ein trauriges ironisches Beispiel für zu viel Security oder ja beziehungsweise eher für eigentlich menschliches Versagen, muss man sagen ehrlicherweise. Was ist denn vorgefallen? Und zwar bei der International Association of Kryptologic Research, kurz IACR. Die forschen an kryptologischen Themen, steckt 'nem Namen. Nein, und
Jan: das mit dem Namen? Das Ja,
Dave: das ist krass. Da hätt man nicht vermutet, aber deswegen sag ich's dir noch mal explizit. Genau und jedes Jahr gibt's sone Wahl für neue Direktoren, Amtsträger so in wichtigen Positionen und dann gibt's dazu halt eine Wahl, wo die Leute abstimmen können. Und die nutzen dafür ein Abstimmungssystem mit dem Namen Helios, so heißt das. Das also das Coole ist natürlich passend auch zu dieser Association, Helios nutzt Kryptografie, dann stimmt vertraulich und konform abzugeben und zu zählen. Aber genau da nimmt der Schrecken jetzt seinen Lauf an der Stelle. Und zwar haben die gesagt so, hey, okay, wir wollen irgendwie verhindern, dass man Wahlergebnisse manipulieren kann, ne, dass irgendjemand hat den Schlüssel und kann dann irgendwas an den Wahlergebnis machen. Also was machen wir? Wir nehmen 3 unabhängige Personen aus dem Wahlkomitee und jeder von denen hat ein Drittel dieses kryptografischen Schlüssels, damit man die Ergebnisse am Ende entschlüsseln kann. Ja, und es muss natürlich so kommen, wie es kommen musste. Eine der 3 Personen hat einfach den Teil des Schlüssels unwiederbringlich verloren, hieß
Jan: es.
Dave: Das hat's nicht mehr gefunden Und demnach war ja dann so, stimmt mal, die Wahl war abgeschlossen und dann haben die gesagt so, ey, wir haben technisch keine Möglichkeiten mehr, an das Ergebnis ranzukommen. Und ich fand das sehr schön, das will ich jetzt zitieren aus dem Post, Und das das fasst es eigentlich sehr schön zusammen, haben natürlich da auch bisschen ihre Lehre daraus gezogen. Und zwar es gibt irgendwie 'n neuen Mechanismus, wie so die gemanagt werden. Es wird immer noch 3 Teile geben, aber es werden jetzt nur noch 2 Schlüssel benötigt, die Wahl zu entschlüsseln. Also ist 'n bisschen runter reduziert worden. Und der Verantwortliche, der den Schlüssel verloren hat, ist zurückgetreten, privwillig. Der hat gesagt, okay, die das kann ich mir jetzt nicht mehr geben. Das ist jetzt vorbei. Geil.
Jan: Also man man könnte vielleicht vermuten, dass sie das vielleicht schon vorher hätten so machen sollen, dass 2 von 3 Leuten vielleicht ausreichend sind so, ja? Weil also kurz den Politikstudent hier raushängen zu lassen, ja, es ist ja auch voll abgefahren für son Wahlsystem, weil nicht nur, dass das so schiefgehen kann, wie Dave grade beschrieben hat, das bedeutet ja eigentlich auch, wenn man mal so böse Absicht unterstellt, dass jeder von diesen 3 diese ganze Wahl Hostage nehmen kann, ja? Und sagen kann so, ja nö, das Ergebnis, das das seht ihr nicht. Das soll lieber noch mal abstimmen, so, ja. Vielleicht gefällt mir das Ergebnis nicht. Und dann sag ich so, oh, ich hab meinen Schlüssel verloren oder ihr kriegt ihn nicht oder
Dave: Ja, Whites was auch
Jan: immer so, oder? Das würdest
Dave: das würdest wir ja nicht sehen, tatsächlich. Also Du kannst das Ergebnis ja erst nehmen, wenn alle 3 ihren Schlüssel dort.
Garrelt: Cool oder vielleicht
Jan: Ja, aber ich kann's auch Man kann sich ja vielleicht denken oder keine Ahnung, weißt Du, die Stimmung war so und so und ich will gar nicht, dass da dieses Ergebnis jetzt so irgendwie rauskommt oder so, ja, okay, nee. Ich werfe meinen Key weg und damit hab ich die Wahl quasi für alle boykottiert.
Dave: Oh. Ja, vielleicht war das sone bewusste Entscheidung sogar.
Jan: Nicht einfach verloren. Krass. Krass. Na gut, nach dieser kleinen lustigen Anekdote hab ich auch noch einen kleinen Konsumhinweis am Ende der Sendung. Und zwar hab ich eine eine Dokumentation geschaut und die hieß Age of Audio. Und was glaubt ihr, worum's da ging?
Dave: Altern. Filme? Ja,
Jan: Altern, genau. Und zwar ging es das Altern von Podcasts. Und zwar, ich weiß, wann wann habt ihr so mit Podcast hören angefangen? Noch gar nichts. Ich wusste, dass mindestens 1 das sagt, ja.
Fabi: Ich weiß nicht, wann gab's denn das erste Mal gemischtes Hack? Dann ungefähr. Ich bin, glaub ich, mein erster Podcast war gemischtes Hack so Folge 19 oder so was.
Dave: Ist das nicht auch während Conage? Nee, schon vorher, oder? Sehr viel vorher.
Jan: 27 September 2017.
Dave: 2017, glaub ich, war das okay.
Jan: Also ja
Fabi: dann war so 2 18, vielleicht, Early 2 18 hab ich angefangen.
Jan: Also meine erste Podcast Experience war noch so, lad dir Podcasts zu Hause auf deinem Rechner runter, spiel sie auf deinen iPod und hör sie dann irgendwie offline unterwegs.
Garrelt: Heute Tag.
Dave: Deine Experience.
Jan: Ist auch schon, weiß ich nicht, fast, das war noch mal eine Schulzeit. Also ist schon ist schon sehr lange her.
Dave: 30 Jahre her? Na ja, faktisch nicht falsch. Da warst Du schon in der Schule.
Jan: Da war ich schon in der Schule, aber es war 'n bisschen später in meiner Zuschauer, ne? Schulzeit so, ja? Aber das ist so eben diese Entwicklung, die Age of Audio, also vielleicht, Sie fangen so ganz vorne an, ne? Wie hat das irgendwie angefangen so als dieses Internet Nischenphänomen? Dann, wie ist das son bisschen größer geworden, als so Public Radio da irgendwie drauf gesetzt hat und dann diese ganzen Comedy Podcasts so den ersten großen Schwung Richtung Mainstream gemacht haben. Wie ist das ganze Thema überhaupt zu Apple und iTunes und dem iPod gekommen, ja? Wieso alles in der Welt hat Apple da keinen Walt Garden draus gemacht, wie sie es mit Apps und anderen Sachen irgendwie gemacht haben, sondern welcher glückliche Umstand war das, dass Podcasts eigentlich bis heute son sehr freies Medium eigentlich noch sind, ja? Und wie ist da so die Zukunftsaussicht? Es ist eine superinteressante Geschichte. Wenn man das Medium irgendwie mag, findet man da auch viele irgendwie Stimmen, die man vielleicht an anderen Stellen schon mal gehört hat irgendwie. Marc Marlon ist irgendwie auch dabei, der ja damals den Mainstream Moment für Podcasting geschaffen hat, als Barack Obama kurz nach seinem seiner Amtseinführung irgendwie mal zu Gast hatte. Mhm. Das muss irgendwie so 2 9 oder so gewesen sein, ja, und dann irgendwie allen da draußen mal klar war, okay, das ist son ernsthaftes Medium irgendwie hin zu dieser ganzen Welle von True Crime Podcasts, die so mit Serial, American Life irgendwie so alles angefangen haben.
Dave: Also es ist
Jan: 'n ganz cooler Film. Wenn ihr die Chance habt, den mal zu sehen, kann ich den nur wärmstens empfehlen, weil ohne die ganze Arbeit von den ganzen Menschen, die da zu Wort kommen, gibt's auch unseren Podcast hier nicht. Von daher, großer Dank schon mal in die Richtung und wie gesagt, sehr schöne Dokumentation. Die
Fabi: gibt cool.
Dave: Wichtige Frage noch, wo kann man sich denn anschauen?
Jan: Noch gar nicht, deswegen hab ich gesagt, wenn ihr dann mal die Chance habt, ich hab da 'n kleinen Preview Link von dem Produzenten gekriegt, noch mal reinschauen zu dürfen. Der sucht grade noch einen internationalen Verleiher und dann wird man mal schauen, ob das entweder in so kleine independent Kinos kommt oder ob das direkt auf 'ner Streamingplattform landet. Schau mal. Aber wenn ich da noch mal News zu bekommen, dann erwähne ich das auch noch mal hier irgend bei uns Super.
Garrelt: Zu den Produzenten?
Dave: Dunkle Vergangenheit. Die Podcast Szene
Jan: ist nicht so unendlich riesig und er hat da in 1 Riesenplattform, wo ich auch immer rumhing gefragt so, hey, ich hab hier eine coole Doku gemacht mit vielen coolen Leuten am Start, würde gerne son bisschen frühes Feedback irgendwie einsammeln, weil Schnitt noch nicht so 100 Prozent final und vielleicht ändern wir noch mal was, bevor wir an Verleiher gehen und so. Und dann hab ich gedacht so, ja, ich melde mich freiwillig und geborene mir mal 90 Minuten. Und hab ich das letzte Woche abends mal gemacht und dann ja, so kam
Fabi: das. So.
Jan: Manchmal muss man einfach nur nett nachfragen und die Leute sind dann gerne bereit, da zu teilen. Es gibt ja auch positive Seiten im Internet. Das ist nicht überall nur Hate und irgendwie Faschismus. Manchmal kann man auch nett sein im Internet.
Dave: Schöne Worte.
Jan: Fabi sieht aus, als würde er widersprechen wollen.
Dave: Nein, ich
Fabi: wollte ein kleines Er wollte
Jan: nur Hate im Internet.
Dave: Er wollte nicht grade hätten. Ja, ich 'N
Fabi: Hate verteilen jetzt am Ende noch mal.
Jan: Nee. Nee. Wunderbar. Dann sind wir durch mit Hate verteilen und wir sprechen uns nächste Woche hier wieder im Podcast. Bis dahin. Tschau, tschau.
Garrelt: Tschau, tschau.
Dave: Tschau, I Lee.