Hallo und willkommen zu Tilpott, Episode Nummer 60. Wieder ein Runder. Hallo Dirk. Hallo Soutjivan. Ich meinte nicht mit Runde. Arsch darf man ja nicht sagen, aber denken darf ich das. Genau. Wir nehmen auf am 19. September. Es ist 19.15 Uhr. Wir sind ja wie die Lage der Nation. Veröffentlichen wir jetzt am 1. Oktober. zwei Wochen, nachdem die letzte Folge rauskam. Und das war quasi auch ein bisschen das Feedback, war schön, dass dann etwas dazwischen kam und mehr so das Feedback war, glaube ich, auch mehr oder weniger gewesen. Wir sollten es dann raushauen, wenn es fertig ist, also wenn wir genug Content auch haben. Genau, und Zwischenepisoden sind gar nicht so schlimm, also ruhig machen. Ja, aber meistens haben wir gar nicht so viel Content. Ja, oder wir haben so viel Content, den wir nicht machen wollen, das ist ja auch schon vorgekommen. Ja, genau. Gut, wir haben aber ein Content lange nicht mehr gemacht. Endlich mal wieder ein Buch-Update. Yippie. Woher wüsstest du das? Ja, böse Zungen behaupten, ich hätte die Planung vor mir. Ja, genau, ein Buch-Update Nummer 31. Und es ist ganz bewusst ein Buch-Update zum DevOps-Buch effektiv. Obwohl es eigentlich ein neues Buch ist. Und zwar bin ich jetzt einer von 1, 2, 3, 4, 5, 6, 7, 8 Autoren des IT-Management-Buchs vom Rheinberg-Verlag. Und da wurden quasi ich glaube zwei DevOps-Kapitel aus meinem Buch, aus meinem DevOps-Buch, wiederverwendet quasi. Zweitverwertet. Zweitverwertet. Genau, auf die Restrepanne. Und Und genau, deswegen habe ich jetzt noch ein Buch, wo ich als Autor dran stehe, wo ich ehrlich gesagt nicht so ganz weiß. Also ich habe den restlichen Text quasi nicht gelesen. Deswegen, aber es geht halt um IT-Management. Ja, verlinken wir es einfach nicht, wenn du es nicht kennst. Aber ja, alles gut. Genau, kommt am 10.10. raus. Ich kriege auch ein paar Exemplare. Wobei ich da auch eine Frage habe. ich bin ja jetzt quasi einer von vielen Autoren bei dem Buch. Und ich hatte halt mit einem, mit dem Mike, Mike Wienströer, quasi das, der ist quasi der Herausgeber, der hat auch ein paar Kapitel geschrieben. Aber er hat das quasi so federführend halt vorangetrieben. Und mit dem hatte ich halt alleine Kontakt. Zu den anderen habe ich nicht mal eine E-Mail-Adresse oder sonst was. Ja. Wie läuft das eigentlich bei deinem Buch? Weil effektiv seid ihr ja auch vier Leute, fünf Leute. Hast du für das Buch keinen Vertrag bekommen? Doch, habe ich. Da steht das ja drin, oder? Nein, ich meine jetzt, wie es von der Organisation für dich läuft. Also wir werden vielleicht machen wir dann auch noch weitere Buchupdates. Ich weiß nur nicht, ob wir die Nummerierung beibehalten sollten. Im nächsten Jahr wird es ja ein neues Adminbuch geben. Wir werden wahrscheinlich im November, also Mitte November, Ende November eine Redaktionskonferenz haben, wo wir die Inhalte festlegen. Und da werden wir dann auch besprechen, wer was macht, weil es steigt ja ein Autor aus bei uns und dann schreibt halt jeder für sich. Ja, okay, das heißt, ihr trefft euch virtuell wahrscheinlich einmal. Einmal, genau. Ja, und dann läuft das Rest komplett async quasi und jeder schreibt für sich. Genau, und wir haben eine Mailingliste, wo wir uns drüber austauschen und wo alle Autoren drauf sind und die einen antworten öfter, die anderen antworten weniger oft, genau, und wo wir dann auch fragen klären inhaltliche fragen klären oder auch formatierungs fragen zum beispiel klären wir werden auch ein komplett neues satzsystem machen wir werden nicht mehr in datech setzen sondern, markdown das wird leicht unterschiedlich werden und ja da tauschen uns darüber aus und da gucken wir dass wir vorwärts kommen und bei uns gibt es einen verteilschlüssel der sich nach der anzahl der seiten richtet die jeder auto genau das. Habe ich auch. Das habe ich. Auch da aber mir ging es auch mehr um die Organisation. Also wie plant man das zusammen? Weil sie macht ja schon wirklich was zusammen bei mir. Also wir verwenden hier, das ist okay. Ich so, ja, macht mal. Also bei uns ist ja so, dass jedes Kapitel komplett nur explizit für dieses eine Buch geschrieben wurde. Das ist ja nochmal was anderes. Und wir haben im Vorfeld natürlich schon relativ viel Austausch via Mail, aber wir wollen dann halt die drängenden Fragen durchdiskutieren, weil da ist dann Mail vielleicht auch der verkehrte Weg. Und da legen wir das dann fest. Das kommt dann auch als Vertragsanhang zu der neuen Auflage dazu und dann wird das dann dementsprechend umgesetzt. Und da legen wir auch ungefähr einen Seitenumfang fest, weil wir sind mit dem Adminbuch an der Seitengrenze, die bindbar ist. Und da müssen dann einige Leute Einschnitte hinnehmen und andere Leute können dann halt vielleicht mal ihr Kapitel ausführlicher machen. Gehilft dann wahrscheinlich ja auch, um ein bisschen so die Themen, die vielleicht nicht ganz so relevant sind, von den Leuten dann auch wieder wegzunehmen, wird es gemeinsam passiert und nicht. Ja, ich habe ein Kapitel zum FTP-Server gemacht. Also ich glaube, mittlerweile kann man in 2025 sagen oder 2026, dass man das getrost weglassen will, weglassen kann. Das wollen wir, das alte FTP-Kapitel wollen wir dann aber zum Download bereitstellen zum Beispiel. Solche Sachen werden dann da diskutiert. Einfach um auch, Ja, das Administrator-Kapitel ist ja auch von mir. So arbeitet ja heute auch keiner mehr. Das werde ich wahrscheinlich komplett neu schreiben müssen, um die heutige Kultur so ein bisschen zu widerspiegeln. Ja. Genau. Kannst du was über DevOps schreiben? Kann ich was über DevOps schreiben? Ja. Ich sage mal, reine Linux-Administration ist ja ein reines OS-Administrator. Da ist nicht ganz so DevOps, außer dass das Betriebssystem nach DevOps-Prinzipien weiterentwickelt wird. Also sprich, konfiguriert wird und aktualisiert wird. System Engineering quasi. Genau, das geht Richtung System Engineering, Plattform Engineering. Oder wie man heute sagt, Plattform Development. Genau. Ja. Genau. Genau. Ja, das IT-Management-Buch kostet 59,90 Euro. Ich glaube, euer ist das auch so teuer, oder? Nee. Oder ist euer sogar teurer? Teurer. Ich glaube, das ist mittlerweile bei 80 Euro, also 79,90 Euro, glaube ich. Ja, aber das hier ist 832 Seiten. Ich glaube, das ist ja schon an die 1000 oder so. 1250 oder so ist. Ja, ist ein bisschen ein kleiner Unterschied. Ja, und bei uns wird halt nicht so viel gelabert wie bei dir. Das ist dann halt auch nochmal ein Unterschied. Nein, Quatsch. Wir haben ja so einen Gemischtwarenladen. Das ist die einzige, Basis für das Thema ist, dass das, für das Buch ist, dass wir alle über Linux schreiben, aber letzten Endes haben wir ja nicht mehr Gemeinsamkeiten in dem Buch. Jedes Kapitel ist analog. 69, 90, ich habe mich vertan. Jedes Kapitel ist eigentlich in sich geschlossen und kann ohne die anderen Kapitel ohne Probleme gelesen werden. Ja, ein klassisches Handbuch halt mal. Ja, genau. 1337. 37. 37, verstanden. Irgendwas um die 1300 Seiten. Ja, sorgt mal dafür, dass es 1337 wird. Das wäre doch schön. Sind leider 1306. Aber ja, 1337 wäre schon cool. Das ist richtig, ja. Das wäre elitär. Wenn man das so hinkriegt auf die Seitenzahl, ja. Und sogar, sagen wir mal so, wenn man das gewollt auf die Seitenzahl hinbekommt, Das wäre natürlich schon cool, ja. Ja, du machst da noch Bilder rein oder sowas. So ein Klassiker aus Schule und Uni. Oder ich erzähle noch ein Schwank aus meiner Jugend, mache die Vorstellung von den Autoren, ja, irgendwie so. Content, den jeder lesen will. Genau. Gut. Prima. Dann kommen wir zum ersten Shorty. Mein Shorty ist Timeblocking. Timeblocking kennt, glaube ich, jeder. Das ist, wenn man sich vor seinen Kalender setzt und einfach in den Kalender einträgt, was man wann erledigen möchte. Das ist natürlich die triviale Form. Ich habe jetzt einen Artikel gelesen, den nicht ganz interessant war, der sagte, dass man sich Zeit für vier Bereiche blockieren soll, für einen Fokusbereich, wo man intensive Arbeit macht, wo man Admin-Aufgaben löst, also so Verwaltungsaufgaben, dass man Zeit für Social einplanen soll, also irgendwelche Sachen, wo man mit anderen Leuten was zusammen macht und einen Recreation-Teil einbauen soll, also wo man sich erholt oder wo man sich schon erholt. Und die Frage, die dahinter steckt, ist, dass man sich im Vorfeld überlegt, zu welchen Zeiten erholen wir uns? Wo finden wir Zeitfenster für echte Konzentrationen? Wie erledigen wir administrative Arbeiten und vor allem wann? Und was sind die Zeiten für Socializing? Das Time-Blocking würde damit auch noch in den privaten Bereich rein strahlen, was natürlich auch nochmal ein ganz anderer Ansatzpunkt ist. Ich habe mir mal überlegt, das mit Lego umzusetzen, einfach zu sagen, ich habe so ein grünes Lego-Brett, was so jeder kennt und würde dann halt das mit Steinen in verschiedenen Farben machen. und würde dann sagen, ein Einmal-Dreistein, also einer, der einen Baustein hoch ist und drei Bausteine breit ist, der würde für eine halbe Stunde stehen und dann einen Halbstundenblöcke in meinem Terminkalender damit belegen. Ich habe mir dann noch überlegt, dass mir diese vier Kategorien eigentlich zu wenig wären und dass ich eigentlich noch so Sachen haben möchte wie Denkzeit. Ich möchte einfach mir überlegen, wann kann ich mich mal hinsetzen, um wirklich nachdenken über Dinge. Also nicht nur Fokuszeit, wo ich fokussiert Arbeit tue, sondern einfach mal auch Zeit, wo ich mal nichts tue, sondern wirklich Zeit zum Nachdenken nutze, ab vom Computer. Oder Lernzeit, Zeit, wo ich Sachen lerne und diese Zeit dann auch für jede Woche fix einplanen. Das heißt, dass ich jede Woche, weiß ich nicht, zwei Stunden mehr explizit Zeit nehme, irgendwas zu lernen. Und bei den ganzen privaten Verpflichtungen ist mir so durch den Kopf gegangen, dass es gar nicht so wahnsinnig einfach ist, weil man braucht ja Zeiten für den Haushalt, man braucht Zeiten für Partner oder Partnerinnen, man braucht Zeit für Kinder oder Haustiere oder Hobby. Hobby wäre Recreation wahrscheinlich. so dass das da eigentlich schon relativ strammes korsett steht wenn man das alles wirklich im vornen dann planen möchte und dann habe ich überlegt ob das nicht einfach zu viel des guten ist. Ja das ist auch mein ding also ich mache es nicht manchmal sollte ich es machen also teile davon zumindest weil mein sportplan quasi macht ja sich auch bemerkbar auf den tagesplan fand ich mit Arbeit anfange oder sowas. Weil ich zuletzt zumindest eigentlich immer Morgensport mache. Ja. Und, ja, und das ist dann halt auch immer die Frage, ob man das jetzt explizit blocken sollte oder wie. Also zumindest ich glaube der wesentliche Punkt da ist, dass man auch feststellt, ob man zu wenig Privatkrams macht quasi. Also mir ist die Idee mit den Negostein gekommen, einfach du hast einen fixen Vorrat an Steinen, den du verplanen musst für die Woche, also dass du sagst, du möchtest, weiß ich nicht, jeden Tag wenigstens eine halbe Stunde Sport machen, dass du dann fünf von diesen Einreihern oder sieben von diesen Einreihern hast, den du irgendwann in deine in deinen Wochenplan aufbauen willst und dann sagst du dir selber als Regel, dass einer von diesen Steinen pro Tag irgendwo auftauchen muss. Ich glaube, das gibt dir ein ganz anderes Gefühl dafür, wie du deine Zeit verbringst an der Stelle. Ja, genau. Und gerade wenn du, du warst ja jetzt neulich in Frankfurt, gerade wenn du solche Tage hast, dann ist das ja mit der Planung dann auch nochmal deutlich schwieriger ja, ja, Oder wenn du sagst, jetzt in deinem Fall, du gehst ja laufen, wenn du in deinem Fall sagst, ich möchte, weiß ich nicht, fünf Stunden pro Woche laufen, dann hättest du halt zehn Steine, die du verballern musst und du weißt genau, an einem Tag in der Woche kannst du nicht, weil du da den ganzen Tag unterwegs bist, dann weißt du halt eben auch, dass du an den anderen Tagen irgendwie die Zeit unterbringen musst. Ja, genau. Einfach so ein haptischer Ansatz, wie man mit solchen Zeitblöcken umgehen kann. Ja, so eine Budgetierung quasi. Genau, genau. Man kann das sicherlich auch mit einer Excel-Tabelle machen, wie man fast alles mit einer Excel-Tabelle machen kann. Nein, man kann das sicherlich auch auf andere Art und Weise machen. Man kann das auch sicherlich im Kalender hin und her schieben. Aber ich finde gerade die Idee mit Lego, die gefällt mir ganz gut. Aber hast du es dann ausprobiert oder noch nicht? Nee, noch nicht. Ich suche tatsächlich noch einen Laden, wo ich mir so Lego-Steine einfach kaufen kann, so viel ich es brauche. Gibt wohl ein paar, aber von denen weiß ich, zum Teil sind das sehr dubiose Internetseiten, von daher weiß ich nicht, was ich so von denen halten kann. Wenn da einer unserer Zuhörer was kennt, wäre ich dankbar für Hinweise. Ich würde das gerne mal versuchen, ob das irgendwie hinhaut. Ich bin gespannt. Ja, ich auch. Dann gibt es einen Time-Blocking Teil 2. Nach dem Buch-Update 33 oder so. Genau. Gut. Gut, gut. Mir fiel neulich was auf und deswegen mal ein Shorty. Das ist auch halb Frage an dich, halb auch an unsere Community. Also von wegen, ich habe das Gefühl, dass früher sehr, sehr viel darüber diskutiert wurde bezüglich X ist besser als Y. Vor allem halt in dieser OSS-Bubble. Klassisches Beispiel Ubuntu versus, keine Ahnung, alles andere. wird gefühlt nicht mehr so häufig diskutiert wie noch vor ein paar Jahren. By the way, I use Arch, genau. Genau. Hast du das Gefühl auch? Es kommt immer darauf an, mit wem du sprichst. Ich kümmere mich ja um Linux-Desktop für unsere Firma. Und da gibt es schon klare Sachen. Der eine sagt, er möchte lieber Void-Linux haben, der andere möchte lieber NixOS haben. Oder der dritte möchte gerne Ubuntu haben, aber dann Ubuntu mit NixOS-Packages. Da gibt es solche Diskussionen schon noch, aber sie werden nicht mehr so heftig geführt wie früher. Das Gefühl habe ich. Ja, das war gefühlt früher immer sehr religiös. Ja, finde ich auch. Und das Ubuntu versus irgendeine andere Distro war ja jetzt nur ein Beispiel. Ja, ja, irgendeine andere Distro ist eh immer besser. Genau. Ja, ich meine, gleich ist wie Android versus iPhone oder sowas. Ja. Mittlerweile ist das auch in der OSS-Bubble, und ich spreche jetzt vor allem von der OSS-Bubble, sehr durchmischt. Ich glaube aber auch, dass ein Teil dem geschuldet ist, dass wir älter geworden sind. Ich glaube, das sind so Phasen, in denen solche Sachen relativ häufig diskutiert werden. Und da sind wir, glaube ich, rausgewachsen. Ja, ich glaube auch, dass es so ein bisschen, wenn es was Neues ist, dass es dann noch mal ein bisschen was anderes ist. Weil das Thema iPhone, Android oder Buntu irgendwas, wenn das noch relativ neu ist, dann wird sowas halt diskutiert. Nach einer Weile halt weniger. Ansible Puppet wird gefühlt auch nicht mehr diskutiert. Also vielleicht ist das auch ein Zeichen, dass die ganzen Themen im Mainstream angekommen sind. Und dass man im Mainstream sich halt die Wahl zwischen zwei ähnlich guten Lösungen hat. Ja. Ja, ich meine, ein paar andere Sachen gibt es ja auch nochmal so, die Lizenzthematiken. Gefühl ja auch viel mehr diskutiert, ob und unter welcher Lizenz eine bestimmte Software steht. Mittlerweile ist das Gefühl so, Hauptsache ist es irgendeine Open-Source-Lizenz. Ja. Ja, wobei ich da schon häufiger mal gehört habe, dass viele Leute sagen, GPL sonst gar nichts. Das höre ich auch immer noch häufig. Ich nicht. Oder dass die Leute sagen, dass Apache-Dizinsen nicht so gut sind, aber ich glaube, das hat sich mittlerweile auf so Statements verkürzt, also nicht auf religiös geführte Diskussionen, sondern mehr auf Statements. Genauso wie Gloom versus KDE versus, keine Ahnung, irgendein Tiling Window Manager. Momentan ist doch Hyperland der Große. Ich habe es bis vor ein paar Tagen nie von was gehört. Ja, der Groß, die neue große Sau, die durchs Dorf getrieben wird. Genau, so wie Python versus Ruby, auch so ein Ding. Ich glaube, Python hat sie da deutlich verbreiteter als Ruby heutzutage. Ja, ich habe zu allem eine Meinung, klar. Ja. Ich bin mit Ruby nie so gut zurechtgekommen, also von daher wäre es für mich da auch eher Python, aber ich glaube, ich muss dir recht geben, gefühlt gibt es diese religiösen Kriege da nicht mehr. Also ein Python vs. Ruby Auseinandersetzung habe ich glaube ich noch nie gehabt. Eher so Python vs. Pearl. Aber da es mit Pearl so irgendwie gar nicht weitergeht und das neue Pearl 6, also das Raku, mehr oder weniger Nischen-Dasein, führt jetzt die Diskussion da auch nicht mehr da. Ja. Das letzte, was mir noch einfiel, war Wim vs. EMAX. Das ist gerade eine Frage. Was war das Zweite, was du gesagt hast? Ja, ich verstehe diese Diskussion auch nie. So, Wim versus EMAX, was ist besser? Ich meine, das ist doch so einfach. Natürlich ist Wim besser. Natürlich. Ja, wobei ich da jetzt häufiger schon gehört habe, dass viele Leute auf Neo-Wim schwören. Ja, das ist jetzt für mich eine Kategorie quasi. Aber das ist Wim versus Neo-Wim. Also das höre ich auch. Achso, ja, gut. Aber mehr so von wegen, die Leute zu überzeugen, auf das Modernere zu gehen. Und nicht unbedingt, weil Wim doof ist, sondern einfach nur, hey, das ist die logische Weiterentwicklung. Ja, und wie ich es gehört habe, ist bei Neo Wim ein Language Server dabei, was natürlich schon einige Vorteile bringt. Ja, aber ja. Aber ich benutze immer noch den Plain Wim. Nein, falsch. Wim Extended oder Wim Enhanced heißt ein bestimmtes Betriebssystem. Ja. Genau. Ich habe den gleichen Eindruck. Die Diskussionen sind viel, viel stärker auf einer sachlichen als auf einer emotionalen Ebene statt. Ja. Und das mit dem Erwachsenerwerden, du bist auch, keine Ahnung, wie viele Jahre älter als ich. 24, irgendwie so. Irgendwie sowas. Aber das heißt ja nicht, dass die Diskussion gab es ja noch, als du 50 warst. Ja, das stimmt schon. Aber heute weiß ich ja, was besser ist, da brauche ich ja nicht mehr drüber diskutieren. Genau. Nein, aber ja, es ist schon richtig. Aber ich habe das Gefühl, die meisten interessiert es auch gar nicht mehr. Ja. Also es ist eher wichtig, dass du ein Konfigurationsmanagement-Tool einsetzt und das ist egal, welches Tool du benutzt, Hauptsache du benutzt eins. Ja, genau, das ist auch meine Devise. Es ist besser, Puppet oder Ansible zu verwenden oder ein Mix aus beidem als Bash-Skript zu schreiben. Ja, also wenn ich zwischen den beiden die Wahl habe, würde ich auch beides nehmen. Puppet zum Konfigurieren und Ansible zum Deployen. Genau hat beides irgendwie seine Vorteile. Finde ich und für den Dienstest, da habe ich mir Solstack überlegt um noch einen anderen ins Rennen zu schicken, weil Solstack einige Features hat, die ich ziemlich klasse finde, die ich ziemlich gut finde. Und da gibt es ja noch Polumi und Chef. Polumi ist eher ein Konkurrent zu Terraform. Ah. Stimmt, ja Ja, oder wie heißt das mit C? Gab es auch noch mal was? Cloudformation. Cloudformation? Nee, ich meine, das wäre was anderes. Also Terraform. Naja, heißt es Cloudformation? Ich dachte, das wäre was anderes. Klingt jetzt nicht so bekannt für mich. Cloudfoundry. Nein, auch nicht. Nee, Moment, das ist die Kubernetes. Egal. Genau, aber Chef unter den normalen, in der Configuration Management-Kategorie. Ja. Genau. Ja, oder auch IDEs ja auch, IntelliJ versus Visual Studio Code versus irgendwas. Jeder nutzt, glaube ich, so das Ding, weil das alles irgendwie mehr oder weniger das Gleiche tut. Und das war's. Ja, also da höre ich auch, da finde ich auch ganz spannend, dass sich da schon fast VS Code quasi als Standard durchgesetzt hat, dass alle anderen nahezu Nischen-Dasein führen, meiner Meinung nach. Ja, kennst du doch Notepad++? Ja. Die Älteren erinnern sich. Oder UltraEdit? UltraEdit gibt es für Mac. Gibt es auch für Linux, gibt es auch für Windows? Achso, ich weiß nicht, dass das bei dem Artikel für die Max-Zeitschrift, den ich neulich geschrieben habe, da sollte ich das nochmal irgendwie, war das wohl Traded? Ich glaube, ja. Ja, kann sein. Ja, aber ja, wir finden ganz viele Beispiele. Das mit C, was ich gesucht habe, ist Crossplane. Ah, ja, ja. Live für Sie gesucht, genau. Genau, hatten wir auch mal in der Folge erwähnt übrigens. Ja, ich glaube auch. Wir erwähnen so viel. Genau. Gut. Gut, gut. So viel dazu. War mehr so eine Feststellung, als was ich eigentlich ganz angenehm finde. Aber es ist eine Sache, die du gelernt hast. Von daher passt es ja schon ganz gut. Ja, genau. Ich weiß noch, damals fällt mir gerade ein, wo noch immer so, ich nutze Ansible und Puppet auszurollen. Witze. Ja, ja. Ja. Ja, weiß ich nicht. Manches ist doch spätpubertäres Gehabe irgendwie, oder? Deswegen meinte ich, wir sind da rausgewachsen. Ich muss auch gestehen, mich interessieren so, ja, ich mag jetzt den Kriegsvergleich nicht ganz so, aber mir fällt jetzt gerade keine Alternativen ein. Mir gefallen so Kriegsgeschichten nicht. Ja. Wo dann jeder so die Anekdoten aus seinem Beruf erzählt und die alle irgendwie auch schon 20 oder 30 Mal gehört haben oder jeder so in einer bestimmten Art und Weise erlebt hat. Da bin ich mittlerweile auch raus, merke ich immer mehr. Ja. Gut, so viel dazu. Ja. Kommen wir zu unserem Hauptthema. Und zwar bin ich mir immer noch so ein bisschen unsicher, wie ich das Thema genau nennen soll, weil eigentlich ist das so ein bisschen Software Supply Chain Security, aber eigentlich geht es mehr um die, also heute für uns jetzt vor allem um die Absicherung des eigenen Software Delivery Life Cycles. Weil mir fiel es auf, dass es sehr, sehr viele Sachen gibt, die man absichern sollte im ganzen DevOps Life Cycle, wenn man quasi alle Stages mal durchguckt, wenn man sicher gehen will, dass kein Schindluder betrieben wird. Endlich mal wieder eine Sache, von der ich keine Ahnung habe. Genau. Und deswegen habe ich jetzt ganz, ganz viele Punkte mitgebracht, die wir mal ein bisschen durchdiskutieren sollten. Und wahrscheinlich gibt es da noch ganz viele Sachen, die ich vergessen habe, die man auch betrachten sollte. Weil theoretisch kann man da richtig viel zu konfigurieren schreiben machen wichtig ist jetzt vor allem mir geht es jetzt darum dass es um echte projekte geht in firmen in open source projekten oder sowas wo und jetzt nicht so die hobbyprojekte die ich allein die ich oder du alleine machen das ist jetzt weniger relevant sondern wirklich die die die wo es auch hinterher am ende irgendwelche nutzer gibt die das ganze dann nutzen. Und du meinst auch Sachen, wo am Ende eine Software rausplumpst und nicht wo eine Plattform am Ende rausfällt, oder? Naja, kommt drauf an, wie du jetzt in dem Fall Plattform definierst. Plattform als Basis von Dingen, wo auf die andere Software laufen können. Ja. Richtung Infrastruktur. Ja, okay. Da ja auch. Wenn der Software entwickelt wird, dann auch. Nein, aber du willst, ja, missverständlich ausgedrückt. Fangen wir einfach an. Genau, weil der Gedanke kam ja neulich häufiger mal, wenn wir mal so ein bisschen gucken, gibt es ja immer mal wieder so Fälle, wo irgendwelche User eine ProDatenbank mal gelöscht haben, obwohl sie es gar nicht sollten. Beziehungsweise durften. Und da stellt sich natürlich auch immer die Frage, okay, warum ist das jetzt passiert? Und wie kann man das verhindern? Wovon das bei mir aber eigentlich kam, ist die ganze Thema um AI-Agents. Weil das war ja neulich auch wieder in der Diskussion, gab es einen Artikel auch wieder, dass irgendwer den Wipe-Coding-Dienst Replit genutzt hat, den ich auch nicht kannte. Und ja, das sprießt ja auch alle drei Tage auf etwas Neues aus dem Boden. wo dann das die AI oder das LLM dann die ProDatenbank gelöscht hat und der User hat dann auch nachgefragt LLM, warum hast du denn das getan? Da kam dann irgendwie so eine Antwort zurück von wegen so, ja ich bin in Panik ausgebrochen und hab's dann irgendwie gelöscht und irgendwie sowas dann halt und dann denkst du, alter, was? Das eine ist natürlich klar, man könnte jetzt die ganze Zeit mehr keine AI-Agents hier und da, vor Nachteile, bla bla bla. Ich finde aber, man sollte auch ein bisschen gucken. Ich glaube schon, dass das ein Ding ist, was sich durchsetzen wird zu einer gewissen Art und Weise. In welcher Art und Weise wird sich noch zeigen. Aber es werden wahrscheinlich immer wieder irgendwelche Agents geben, die man auf den Source-Code loslässt, der dann was tun soll. Und wenn wir jetzt mal gucken, wie können wir auf der ganzen Software-Delivery-Lifecycle was absichern, damit sowohl normale Nutzer als auch AI-Agents nichts kaputt machen können. Ich habe bei AI-Agents, die würde ich ein bisschen raushalten wollen, weil ich glaube, wir müssen ein Verständnis dafür bekommen, dass wir die nicht ohne Kontrolle irgendwas machen lassen. Genau. Ja, also da muss immer noch irgendwie, wir haben ja, bei Vibe-Coding-Ingenieur hat der Stefan mal irgendwo in Mastodon geschrieben. Ich finde den Vibe-Cleaning-Ingenieur auch ganz witzig, die Leute, die halt hinter den Vibe-Coding-Ingenieurs aufräumen. Also ich glaube, wir müssen einfach verstehen, dass das ein Werkzeug ist und dass das je nach Fragestellung sogar ein sehr schlechtes Werkzeug ist und dass das einfach überprüft werden muss, dass man das nicht alleine machen lassen darf. Genau, aber wo ist jetzt der Unterschied zu einem echten Menschen? Dass ich beim echten Menschen, also kommt auch auf die Größe des Menschen an, ein echter Mensch mit drei Jahren, den würde ich auch ständig überprüfen, einen echten Menschen mit, weiß ich nicht, 20 Jahren Berufserfahrung, da würde ich nicht so stark kontrollieren. Genau, und da kommt natürlich die Frage, was heißt Kontrolle genau? Und genau darüber reden wir jetzt über die einzelnen Punkte, weil es kommt jetzt sehr stark auf die einzelnen Punkte an. Weil das Erste, was nämlich mal so angeht, ist die Berechtigung auf dem Repository. Wir machen jetzt in dieser Episode erstmal nur den CI-Part quasi, was quasi Source-Code-Management, Bild und Test ist. Alles, was danach kommt, machen wir wahrscheinlich in der nächsten Folge oder vielleicht auch danach mal. Für welches INCI hast du dich entschieden? Integration. Okay. Nicht Implementation. Achso, nee. Ich dachte an CI, CD, deswegen. Ja, aber es gibt auch da verschiedene Spielformen. Deswegen habe ich jetzt gefragt. Integration. Gut. Genau, so die Berechtigung ist natürlich ein großes Thema. Das zieht sich eigentlich durch alles durch. Das ist aber so ein bisschen schwierig, das aufzudröseln in allen. Deswegen müssen wir da so ein bisschen unterscheiden. Das fängt schon damit an, wer darf Repositories anlegen. Weil dahinter ist ja meistens eine Owner-Rolle, der halt alles darf. Ein normaler User. Was auch nicht so toll ist, weil dieser kann meistens dann halt alle Sicherheitsmechanismen, über die wir gleich sprechen werden, wieder abschalten. Ob jetzt Bewusstse oder Unbewusstse, erst mal dahingestellt. Aber das ist nicht so praktisch. Deswegen muss man eigentlich, und das machen viele Firmen auch, die einen quasi Bestellprozess für Repositories auch haben, wo es dann keinen normalen Nutzer gibt, der Unerrichte hat. und sondern halt maximal maintainer recht oder sowas hat um eben sicherheitsmechanismen nicht abschalten zu können das kommt dann für oder halt auch repositoris löschen können weil theoretisch wenn du ohne recht an einem repo hast kannst du es halt wieder weglöschen ungünstig. Wir reden aber von repos die irgendwas produziert wo irgendwas verwaltet wird was später auch in produktion gehen sollen. Weil generell. Ist ja ein repo gar kein schlechtes ding also wenn ich jetzt für meine privaten Dot, falls ein Reeper wollte, müsste es ja nicht so ein Laubprozess durchlaufen. Genau, da müssen wir unterscheiden zwischen echten Projekten. Deswegen sollten die Rechte dann auch nur für eine bestimmte Gruppe geben, wo quasi alle relevanten Sachen drin sind. Du kannst ja deinen privaten Kran quasi, und mit privat heißt das jetzt, was du für deine Arbeit brauchst, kannst du ja in deinem privaten Profil hinterlegen und gut ist. Ja, einverstanden, passt. Wobei mir auch gerade auffällt, theoretisch kannst du damit dann ja auch wieder was umgehen. Ja, es kommt auf ein, ob du dahinter die Pipelines anbinden darfst. Da gibt es ja auch nochmal eine Möglichkeit, durch Berechtigung Dinge zu steuern. Genau, und ob du irgendwo hin deployen darfst, das musst du natürlich abgrenzen, aus welchen Dingen das kommt. Aber deswegen, man merkt jetzt schon, dass es gar nicht so einfach, wenn man wirklich alles betrachten möchte. Ohne die Berechtigung so stark einzugrenzen, dass es keinen Sinn mehr macht, das zu nutzen. Ich war jetzt gerade kurz versucht zu sagen, das geht so ein bisschen nach gesunden Menschenverstand, aber ich habe leider im Berufsleben erfahren, dass es sowas wie gesunden Menschenverstand einfach gar nicht gibt. Genau. Deswegen meinte ich dann halt auch, es ist dann auch egal, ob es ein AI-Agent ist oder ein normaler Mensch, wenn jemand Schindluder betreiben will, kann er es tun. Was ja auch nochmal hinzukommt, ist, wenn dein User-Account komprimitiert wurde, das kann jetzt einfach nur, weil jemand deine Zugangsdaten hat und kein Two-Factor Authentication Vielen Dank. aktiviert wurde, auch ein Ding, was man machen sollte, sind wir eigentlich immer noch beim User-Management, kann dein Account ja übernommen werden und kann Dinge tun mit den Berechtigungen, die du hast. Deswegen, je weniger Rechte du hast, aber die du trotzdem benötigst, desto weniger kann kaputt gehen natürlich. Was es natürlich gibt und was häufig gemacht wird, ist, dass es einen User gibt, mit dem du tagtäglich arbeitest und meinetwegen auch Software entwickelst. Und dass es auch einen User gibt, mit dem du Admin-Aufgaben durchführen kannst. Und die User sind voneinander getrennt. Beide sind auf dich als Person zurückzuführen. Genau. Ja, so war es bei GitLab auch. Da hat er dann das Team, was sich um die Security gekümmert hat bei Incidents. Also um tatsächlich Security-Incidents. Die hatten dann halt nicht deren normalen Account genutzt, sondern haben sich nochmal zusätzlich über einen separaten Account, authentifiziert, um auf die ganze GitLab.com-Instanz zugreifen zu können, was sie mit dem normalen Account halt nicht können. Das ist das gängige Praxis, das kenne ich auch so, ja. Genau. Und sowas muss man hier natürlich auch betrachten, dass dann dieser technische User dann halt nur dafür genutzt wird und dann auch stark reguliert wird. Wie genau man das jetzt technisch umsetzt, ist sogar egal, das soll ja auch kein Beispiel sein, ob jetzt GitLab, GitHub oder sonst was. Aber so der Gedanke, es sollte halt ein bisschen klar sein. Und dann kommen wir nämlich ja auch nochmal dazu, dass wenn du dein User-Account, komprimitiert worden ist, das kann ja auch sein, wenn du ein Token hast, ein API-Token, der deine Berechtigung hat. Damit gehen die meisten Sachen halt eher kaputt, dass da irgendwo was geleakt ist. Und dann hat man ja auch wieder Zugang auf einen vollen Account. Da kann was kaputt gehen. Deswegen ist es immer schön und gut, wenn man da sagt, ja, ich vertraue meinen Mitarbeitern und bla bla, aber ja, dann ist irgendwo ein Credential geleakt, schlecht. Und das gibt es auch nochmal ordentlichen Token Policy, dass die regelmäßig rotiert werden müssen, dass wenn die auch ein paar Monate raus sind, dass sie dann nicht zu einem Problem werden. Ja. Weil einige AI Sachen, die hängen sich ja auch einfach an den normalen Account dran und dann hast du es dann auch wieder den normalen User Account, den er da nutzt. Ist dann auch nicht unbedingt praktisch. Und da gibt es wahrscheinlich noch ganz viele aus den Sachen, aus den Berechtigungen. Wir machen jetzt mal weiter, weil ansonsten werden wir heute nicht fertig. Ja, klar. Weil wenn wir jetzt mal gucken und sagen, okay, wir möchten jetzt den Coding-Teil machen, dann fangen wir ja an, Code zu schreiben. Und da ist aber relativ normal, würde ich sagen, dass es diverse Branche-Protection-Rules gibt. Also was machen wir mit diesen Branches, wo, was der Hauptentwicklungszweig ist. sei es Main, sei es Develop oder wie auch immer der genau heißt und da ist es halt eher wichtig, dass das alles nur nach einem Review zu dem Branch läuft, sodass dann halt nach einem Review jemand anderes, also nach einem Merch oder Pull-Request jemand das abnicken muss, eine andere Person, nicht man selbst das wäre dann auch ein bisschen sinnlos, dass man keinen direkten Push auf den Main oder Develop-Branch machen kann, dass man keinen Force-Push machen kann und dass man so dann halt die normalen Branches dann auch entsprechend schützt, und das alles nur über ein Code-Review laufen muss. Das würde ich sagen, ist schon relativ Standard. Viele haben aber zwar einen Review-Prozess drin, aber theoretisch kann man den umgehen und selbst Sachen merchen. Das sehe ich dann trotzdem immer noch häufig. Ja, da habe ich auch schon erlebt, dass wenn zu viele Merch-Requests kommen, dass dann auch nicht mehr in den Merch-Request selber reingeguckt wird. Also da muss man glaube ich auch relativ, klar sein, was man alles gemercht haben möchte oder wie man da eine Policy hat. Also wenn man alle fünf Minuten Merge-Requests hat, dann guckt da keiner mehr rein. Ja, oder wenn die halt so groß sind, dass die nicht reviewbar sind. Ja, also du meinst, spielt sie in Richtung Atomic Changes, ne? Also dass man relativ kleine Atomara-Changes macht, ja. Genau, aber es macht auch keinen Sinn, wenn du zehn verschiedene Merge-Requests für ein Thema hast. Ja, auch das habe ich schon gesehen, ja. Ja, das ist irgendwo der Mittelgrund, aber lass uns mal nicht zu sehr darauf fokussieren, aber einfach nur, dass dieser Sicherheitsaspekt darauf halt mal gucken, dass wir das dann haben. Was mir dabei aber noch auffiel ist, naja, es ist ja schön, wenn wir die normalen Branches gesichert haben, also die langlebigen Branches, aber eigentlich kann es ja auch ein Problem sein, wenn ein Feature-Branche, wo ich ein paar Tage daran gearbeitet habe, wenn der von wem anders gelöscht wird. Klar, du kannst, hängt es natürlich auch ab, wie es eingerichtet ist, weil wenn ich jetzt, wenn nur ich das selbst löschen kann, dann ist ja alles gut, wenn aber theoretisch anders hingehen kann und das löschen kann, was häufig der Fall ist, dann ist das irgendwie nicht ganz so praktisch. Und theoretisch, wenn du streng bist, müsstest du das auch reinschränken. Also klar, wenn jeder mit seinem eigenen Repository arbeitet, dann ist das weniger das Problem. Aber wenn halt alle auf demselben Repository arbeitet, was ein bisschen Overhead verringert, dann müsste das gemacht werden. Also wenn man nicht mit Forks arbeitet. Genau. Theoretisch gibt es da wahrscheinlich doch ganz viele Sachen zu gucken. Da hat man natürlich eventuell das Problem, dass angenommen, es ist irgendein Incident da und du hast das Problem, dass jemand, dass nur einer da ist und du musst jetzt aber um Prot zu fixen irgendein Deployment machen und ein Commit machen, da ist kein Reviewer da. Was machst du dann? Einen Reviewer besorgen oder ich mache das ding also entweder ich lebe das oder ich lebe es nicht. Genau aber da sind wir effektiv eigentlich wieder bei dem punkt was auch vorhin hatten ist es könnte dann ja auch immer noch einen separaten technischen user geben oder einen user mit mehr rechten geben wo man sich einloggen könnte wenn für den fall aber dann muss es natürlich auch ordentlich gelockt werden und geguckt werden oder benachrichtigt werden wenn sich jemand einloggt und da was er prüft ja. Aber vielleicht muss es dann noch sowas geben wie ein Team Lead on Duty oder sowas oder Manager on Duty, der sich um solche Sachen dann auch kümmern kann, wenn es wirklich in Bereitschaftszeiten passiert. Ja. So richtig geguckt habe ich jetzt auch nicht, wie das andere machen, aber so in die Richtung muss es dann letztendlich dann auch gehen. Hängt natürlich auch ab, wie groß das Unternehmen ist oder sonst was, ne? Ja, und von der Kritikalität der Anwendung hängt es natürlich auch ab. Gar keine Frage, ja. Genau, und da kommen wir nämlich auch zu dem nächsten Punkt direkt. Bei den Code-Reviews, wenn man sich mal genauer die Änderungen anguckt, kann man den Code ja auch nochmal unterteilen in wer muss das erproben? Muss es eine Random-Person sein aus dem Team? Muss es vielleicht mehrere sein? Das macht ja auch Sinn. Oder müssen es bestimmte Leute sein? Weil es gibt sowohl in GitLab als auch in GitHub und ich glaube bei den anderen wahrscheinlich auch eine Code-Owners-Datei. Wo du halt sagen kannst, wie alle Changes, die im Doc-Verzeichnis sind, muss das Technical-Writing-Team abnicken. Alles, was unter dem anderen Verzeichnis ist, muss bestimmte andere Personen oder Personengruppen abnicken und so weiter. Das kann natürlich dann auch hilfreich sein, die richtigen Personen zu haben, weil es bringt halt dann auch nichts, wenn sie die Falschen sind. Ja, vor allem wenn jemand, der nur in einer Sprache programmiert, Merge in einer anderen Sprache abnicken soll, das ergibt auch keinen Sinn. Ja, genau. Und was man dann halt auch immer machen sollte oder müsste konfigurieren ist, ist auch vergleichsweise Kleinigkeit, meistens ein Haken. Naja, der Autor selbst darf nicht seine eigene Matriquests approfen, das aber auch keinen Sinn macht. Und wenn du einen neuen Push machst auf den Branche, wenn du eine neue Änderung pusht, dass sich dann die Approvals wieder resetten. Ist meistens auch nur ein Klick auf ein Config Change. Ja, also ehrlicherweise muss ich sagen, ich wusste gar nicht, dass das konfigurierbar ist, aber es ergibt total Sinn, ja. So, was dann da jetzt noch hinzukommt, ist, dann hatte ich halt auch so überlegt, naja, eigentlich, wenn du jetzt so das nach Zero Trust guckst, dürften die Rechner, lokalen Rechner ja auch nicht, vertraut werden. Weil du kannst ja einen Agent einfach über deinen User-Account auf deinem Laptop installieren und laufen lassen. Wenn du die Rechte hast, hast du das auf deinem Laptop zu tun. Genau. Beziehungsweise kann ja auch passieren, dass nur weil du in einem Repo arbeitest, mit deinem AI-Agent, dass er ausbricht, auf einmal in das Nachbarverzeichnis geht und da Dinge tut und Dinge kaputt macht. Und halt auch dann Brunches pusht oder sowas. Und da müsste man, wenn man streng ist, das eigentlich auch komplett abschotten. Also richtig abkapseln, sodass die Repos nur für sich alleine sind, wo du nicht ausbrechen kannst. Also in Sandboxes zum Beispiel, oder? Genau. Da gibt es auch so Dienste wie Gitpod. Gitpod hat sich neuerdings umbenannt, weil die jetzt auch ganz viel AI machen. Entschuldigung, ja. Die haben auch ihre eigenen AI-Agents. Genauso wie GitLab, genauso wie GitHub, genauso wie alle anderen auch. Und ich habe ganz bewusst die drei genannt, weil alle haben halt diese Remote Development Capabilities, wo du effektiv eine IDE, was in der Regel Visual Studio Code oder ein Fog davon ist, im Browser hast, wo die Container, die du dafür laufen lassen musst, um deinen Dienst zu entwickeln, dass die halt auch auf einem Kubernetes zum Beispiel im Backend laufen, dass du lokal quasi eigentlich nur einen Thin-Client hast und dass die ganze Entwicklung, die du halt machst, in dieser Umgebung abläuft, die halt einfacher zu handeln und zu abzusichern ist, als jetzt dein, Laptop, mein laptop wie auch immer kann man auch machen ja vorteil da ist halt dass es halt auch einfacher steuern kannst du dann noch irgendwelche reporting auditing logging dann noch mit reinbauen will was wer wie gemacht hat kannst du theoretisch dann ja auch noch mit einbauen praktisch weiß ich nicht ob das schon jemand überhaupt gemacht hat ginge halt ja rein theoretisch einfacher als jetzt lokal. Ja, es kommt davon, wie es konfiguriert ist. Ich kümmere mich ja gerade ziemlich intensiv um das Workplace-Thema. Und es gibt Möglichkeiten, dass du die Compliance eines Gerätes testest, sehr ausführlich. Und nur Geräte, die compliant sind, dürfen mit Conditional Access auf bestimmte Dinge zugreifen. Also da hast du ja schon auch Möglichkeiten zu schauen, ob das lokale Gerät kompromittiert wurde im Rahmen bestimmter Parameter und auch nur sagen, wenn das compliant ist, dann darf überhaupt jetzt auf das Code-Repository zugegriffen werden, sonst gar nicht. Ja, genau. Es gibt verschiedene Implementierungsmöglichkeiten. Also irgendwie sollte es halt abgeschottet sein, wenn man es streng nimmt. Auf die eine oder andere Art, genau. Genau, genau. Das sind ja zwei verschiedene Beispiele, wie man es machen könnte. Genau, passt. Das nächste Thema ist, wusstest du, dass du deine Commits signieren kannst? Ja. Und wie? Mit dem GPG-Key zum Beispiel. Genau, damit kannst du es machen und dann kannst du halt auch mehr oder weniger sicherstellen, dass da auch eine echte Person hinter ist. Musst du natürlich auch richtig einrichten. Aber damit kannst du natürlich dann auch nochmal deine Dinge signieren, sodass du weißt, dass du das warst, im Vergleich zu einem Agent, der von dir angesteuert wurde oder sowas. Oder du hast es abgenickt, wie auch immer. Ja, aber das kann Augenwischerei sein. Natürlich. Weil letzten Endes Leute durchaus, die lokal Zugriff auf GPG haben, durchaus auch die Passphrase rauslöschen können. Aus dem Secret Key. Und damit würde jeder sein können, der Zugriff auf die Maschine hat. Genau. Kann ja auch bei Smartcard oder sonst was gehen. Natürlich. Es gibt ja auch ein paar. Natürlich. Ein paar X509 irgendwas. Oder YubiKeys, NitroKeys, was auch immer. Genau. Darauf gehen wir jetzt mal voran aus, dass du den Secret Key nicht irgendwie modifizieren kannst. Alles gut, ich wollte es nur erwähnen. Absolut. Und damit kannst du dann zumindest sicherstellen, dass das tatsächlich mehr oder weniger sicherstellt, dass da eine Person hinter ist. Aber auch wenn die automatisch generiert worden sind, kann ja auch sein, was ja auch okay ist. Ja, oder ich stelle sicher, dass es von einer bestimmten Maschine gekommen ist. Das wäre ja auch noch eine Variante. Oder sowas, ja. Genau. So, das war es soweit zum reinen Source-Good-Management. Ja, wobei ein Teil, der ein bisschen überlappend ist, SAST, also Step-Tick Application Security Testing, das ist ja mehr, den regulären DevSecOps Ansatz auf den Security-Fokus, dass du deinen Code auf Vulnerabilities checkst, also den auf statische Analyse machst. Das kannst du halt einmal in der Pipeline machen, dann würde es halt erst in der Test-Stage quasi kommen, aber theoretisch kannst du es ja auch lokal laufen lassen. Lässt sich natürlich abschalten oder auch nicht abschalten, je nachdem. Ich würde gerne noch eine Sache ergänzen wollen, über die wir jetzt nicht gesprochen haben und das ist, wenn man wir kommen gleich noch zum Dependency-Scanning, aber wenn wir wenn du dir Open Source, nimmst und den Quelltext einfach einbaust also Quelltext, den du nicht selber geschrieben hast, einbaust. Und je nach Umfang wird das dann nicht mehr trivial sein, um herauszufinden, wo das Problem liegt. Ja. Aber das hast du ja mit AI-Agents und Copyload und sonst was ja eh. Ja, also wie gesagt, ich sehe das gerade, AI ist nochmal ein ganz eigener Schnack, aber ich sehe das gerade ein bisschen losgelöst von AI-Agents, sondern einfach, wir sprechen viel über Open-Source-Software und ich könnte mir auch einfach statt eine Bibliothek als Dependency reinzuholen, kann ich hier einfach sagen, ich kompiliere mir die gleich mit und nehme in den Quelltext mit rein. Ja, natürlich. Du kannst auch nicht alles abdecken. Genau. Ich meine, wir versuchen ja auch so möglichst viele Löcher wie möglich zu stopfen. Ich fand die Analogie von MyTiny and Kim zur Corona-Pandemie irgendwie spannend. Von wegen, du hast halt Käsescheiben, wo Löcher drin sind. Und wenn du verschiedene Käsescheiben von verschiedenen Stacks quasi aufeinander stapelst, dann werden die Löcher immer wieder überdeckt von anderen. Auch wenn du theoretisch eventuell dann durchziehen kannst. An einigen, je nachdem, wie groß die Löcher sind. Das Bild ist gut, ja. Und das finde ich dann auch irgendwie spannend. Weil wir versuchen natürlich dann auch so angenehm wie möglich zu halten, das entwickeln, weil ansonsten macht es auch keinen Sinn. Weil ansonsten passiert ja auch wieder, dass irgendwer Schatten-IT aufbaut. Ja, wenn du es komplizierter machst, dann wird sicherlich irgendein findiger Entwickler eine Lösung finden, die drumherum kommt. Ja, das sehe ich genauso, ja. Gut, gehen wir mal zum nächsten Punkt, nämlich der Build-Stage. Das ist einmal so Sache wie Dependency-Scanning. Das geht jetzt so Hand in Hand mit dem ZAST auch. Dass da mal natürlich geguckt wird, gibt es irgendwelche Abhängigkeiten, die Lücken haben. Relativ normales DevSecOps-Verhalten, würde ich sagen. Und da ist natürlich auch die Frage so, okay, welche Quellen akzeptiert man jetzt? Also was sagen wir ist sicher? Was ist vielleicht nicht sicher? Es ist nicht so einfach. Ich hatte schon mehrfach die Diskussion in meiner GitLab-Zeit gehabt mit Leuten, wo dann zwei Leute, drei Leute waren, die meinten so, ja, wir wollen alle Abhängigkeiten prüfen, die mirroren wir quasi auf unser Artifactory, Nexus und Co. Und alles andere ist nicht erlaubt. Ich so, ja, viel Spaß, dann könnt ihr eure Firma dicht machen. Weil mit drei Leuten kannst du das nicht machen, vor allem egal, welche Programmiersprache. Also klar, alle haten über JavaScript und NPM, aber eigentlich hast du es ja bei jeder Programmiersprache. Ja, definitiv. Also ich kenne auch den Weg über Artifactory und dass ein Security Scanner X-Ray in Artifactory eingesetzt wird. Wenn der Scanner ausfällt und man muss dringend deployen, dann hat man halt auch ein Problem. Alles schon gesehen. So, und da macht es aber trotzdem eventuell Sinn, eine Whitelist quasi oder eine Allow-List zu haben von Dependency-Quellen. Das kann jetzt halt auch ein lokales oder ein wie im internes artifakt wie nexus was auch immer sein, wo geprüfte sachen drin sind oder semi geprüfte sachen drin sind die können auch automatisch synchronisiert sein so dass man damit sicherstellen kann so okay wenn jemand versuchen typosquatting zu machen dass das nicht mit rein landet weil die vielleicht schon auf, auf dem Zwischenlayer mit draußen sind. Ja. Für die, die nicht wissen, was Typo-Squatting ist, Typo-Squatting ist effektiv, wenn du keine Ahnung, welches Beispiel haben willst, wenn du irgendeine Abhängigkeit installieren möchtest und du einen Tippfehler mit einbaust, und dann halt eine ziemlich ähnliche Lippe geholt wird, nur mit einer Lücke drin, weil, statt Pip-Install Pandas wird dann Pip-Install Pundas installiert, was aber nicht auffällt, aber halt eine Lücke mit reinholt. Also ihr kennt das bestimmt vom Web, wenn ihr mal die Domain nicht richtig eingebt. Ja. Und statt der Domain, die Seite, die ihr wirklich sehen wollt, dann irgendeine andere Seite auftaucht, nur weil ihr einen Tippfehler hattet. Das glaube ich, daran kann man es relativ gut sehen. Genau, das eine kannst du quasi machen, okay, du machst das über einen White-Listing oder Low-Listing-Test auf den Dependency-Squellen, dass du dann sagst, okay, wenn es von es lässt sich natürlich auch verschieden sticken. Entweder sagst du, okay, es ist nur das, was wir von einer vordefinierten Liste quasi von sagen wir jetzt mal NPM, PyPI und Co. halt haben, die wir rein mirroren, die Standardsachen und alles andere machen wir halt nicht. Aber es kann ja auch einfach sein, wir machen jetzt so einen Typosquoting-Test. Da gibt es mittlerweile auch ein paar Tools zu, die das dann halt quasi gucken, ist das vielleicht eine Library, die nicht da drin sein sollte. Das kann halt auch helfen. Ja, es gibt ja mittlerweile für alles irgendwelche Tools. Und das Tool kann auch einen Fehler haben. Oder Lücken haben. Oder sogar Lücken haben, ja genau. Also man kommt von hundertstens ins tausendste, wenn man nicht aufpasst. Und das muss ja ganze, das Ganze muss noch arbeitbar sein. Genau. Weil das gleiche so bei Container Scanning, du kannst dir einfach ein Oboto-Image ziehen. Musst du quasi sicherstellen, dass das auch von einer richtigen Quelle kommt und nicht von woanders. Weil das kann ja auch passieren. Das heißt, also A, du musst das Container scannen, den Container scannen, aber du kannst ja auch scannen, was für ein Bild, Basis-Image nutze ich hier. Ist es ein erprüftes oder nicht? Und wenn nicht, dann haue ich das raus. Hat Docker Hub nicht sogar die Möglichkeit, dass die einen Verified-Fleck drin haben, wo Sachen gescannt wurden? Ja, mittlerweile gibt es einige Firmen, Docker, ShaneGuard und Co., wo es dann auch, oder Bitnami, die alle so Bitnami ist böse. Ja, weil Bitnami VMware ist und VMware ist Broadcom, ja. Und die sind teuer, wollen alles teuer machen, aber egal. Genau, aber die bieten halt mittlerweile halt auch Zero CVE Container Images an, wo die sich darum kümmern, dass das Basis Container Image sicher ist. Kann Sinn machen, dass sie einen Nutzen in Firmenumgebungen, weil das selbst zu verwalten ist auch Aufwand. Ja, genau. Also wenn du ein sicheres Basis-Image hast, ist das sicherlich ein guter Anfang. Du kannst ja sagen, wenn du Container-Images vom Hersteller bekommst, wenn du eine eigene Registry hat, ist das gut. Letzten Endes musst du den fertigen Container dann doch wieder scannen. Ja, das sowieso, genau. Also du kommst um Scannen generell nicht drum rum. Also die Frage ist, an welcher Stelle du scannst. Genau, beides. Ein Pre und Post quasi. Ja, exakt. Ein Pre-Build und Post-Build. Und in dem Pre kannst du vielleicht dadurch ausschalten, dass du sagst, ich erlaube nur sichere Registries. Genau, genau. Sichere Registries und oder eine Allowlist quasi an Container-Busis-Images. Ja, genau. Genau, aber da merkt man wieder noch ein weiterer Punkt, wo man theoretisch eine Sicherheitsdinge abwärmen muss. Ich meine, einige Firmen versuchen ja schon, Firmen intern ein, sichere Basis-Container-Images zu machen, die dann von anderen Teams genutzt werden müssen. Ja. Sollten. Aber das dann durchzusetzen, da fehlt dann teilweise wieder das Tooling. Ja, und nicht nur das Tooling und manchmal aber auch das Commitment von Management. Also solche Scanner kosten in der Regel auch ein bisschen Geld. Manchmal sogar ein bisschen viel Geld. wenn man security will dann ist es halt mit mit dem preis tag versehen so dass ich. Meine nichtmals die scanner selbst sondern so die arbeitsweise. Ja wenn. Jetzt drei leute hast die sichere container images bereitstellen. Für die ganze firma da wollte ich im zweiten halbsatz drauf kommen ja dass das dass der aufwand natürlich auch geld kostet ja genau genau genau. So, nächster Punkt. Wenn die Pipeline losläuft und das Ding wird gebaut, musst du ja auch dafür, sicherstellen, dass die Build Agents auch entsprechend isoliert sind. Heutzutage glaube ich weniger ein Problem. Zu Jenkins-Zeiten war früher das eher so ein Problem, weil theoretisch hattest du dann ja mehrere, Jenkins-Jobs, die auf demselben Haus liefen, die theoretisch auf das andere Verzeichnis drüber malen konnten. Ja, die Jenkins-Zeiten sind nicht vorbei, ne? Also, je nachdem, wo du arbeitest, wird immer noch Jenkins eingesetzt. Ich meine jetzt aber auch, mittlerweile nutzen ja viele Jenkins ja auch, also Jenkins hat viele Probleme, aber wenn du das über Container baust und das über einen Kubernetes-Cluster läuft, dann ist es ja nochmal ein anderes Ding, als wenn das fixe, feste, Jenkins-Nodes sind, die nie aufgeräumt werden, wo ganz viel Müll rumliegt. Der Unterschied ist wichtig. Ja, das wäre dann eher ein dynamisch generierter Build-Agent gegenüber einem statischen Build-Agent, der vor sich hinschimmelt. Genau. Und auch da kannst du die Build-Agent ja auch isolieren, wenn das in den Kubernetes zum Beispiel läuft, was ja relativ Standard mittlerweile ist, in modernen Setups, sagen wir so. Weil da kannst du dann ja auch nochmal Kubernetes eigene Sicherheitsmechanismen mit einbauen, dass egal welcher Code da drin läuft, dass er nicht an bestimmte Quellen dran sollte oder sowas, weil du kannst ja theoretisch auch nochmal auf Netzwerkebene hingehen und gucken so, okay, versucht der jetzt hier auf NPM drauf zu gehen, was er nicht sollte, dann blockt das hier mal ab, auch wenn das auf anderen Ebenen schon versucht wurde zu reduzieren. Ja, man kann ja sogar so konfigurieren, dass der gar nicht nach außen gehen darf, sondern dass der nur von Input leben darf. Genau. Ja. Und da muss man natürlich dann auch gucken, dass niemand anderes Build Agents an das GitHub, an das GitLab, was auch immer, anschließen kann. Weil sonst kannst du es da wieder umgehen. Ja, wobei ich natürlich gerade Quatsch erzählt habe, einen Weg nach draußen muss es geben. Das alte Fakt muss ja irgendwie auch raus. Ja, aber das kann ja auch ein internes System sein. Ja, natürlich. Sollte in jedem Fall. Ja, genau. Ja. Genau, so. Und deswegen, das ist ja alles eigentlich Wissenschaft für sich. Also jeder einzelne Punkt, den wir so nennen. Da gibt es, könnten wir noch zu jedem Punkt nur einzelne Folge zu machen. Selbst ich, ohne dass ich Ahnung davon habe, könnte dann noch was zu erzählen. Ja, genau, da merkt man erst mal, wie tief das Ganze ist, weil ich bin jetzt ja auch ein ganz Security-Experte, aber das sind ganz viele Punkte, die du theoretisch ja auch schon abfrühstücken kannst. Ja. Mit per Scripting oder sonst was. Genauso wie Reproducible Builds. Es gibt ja auch die Website Reproducible Builds, das gibt es auch schon seit über zehn Jahren. Dass was aus der Open-Source-Ecke halt kommt, dass wenn du ein Debian-Paket baust, wenn du es lokal baust und wenn es auf dem Build-Server baust, dass genau das gleiche Image bei rauskommt, wo auch die Hash-Summe gleich ist. Das willst du innerhalb der Firma oder so ja auch haben, damit du sicherstellen kannst, dass es auch wirklich das richtige Bild ist und nicht irgendwas anderes. Kennst du Fälle, wo Sachen über zwei Wege gebaut werden, um zu schauen, ob die Ergebnisse identisch sind? Nee, aber theoretisch sind die meisten ja auch nicht richtig gebaut. Ja, aber du weißt, worauf ich raus möchte. Wenn du es reproducible machst, muss ja, egal über welchen Weg du gehst, das gleich am Ende rauskommen. Genau, aber theoretisch müsste das ja das Ziel sein. Weil damit stellst du dann ja auch sicher, dass das Nix modifiziert wurde. Weil du kannst ja auch die Bildumgebung kann ja auch kompromittiert sein. Und dann wird ja lokal und auf den Bildservern was unterschiedliches bei rauskommen. Weil wenn wir uns die XZ-Lücke von vor einer Weile angucken, da wurde dann ja in dem Fall zwischen, unter anderem, beim Bauen wurde das halt lokal irgendwo gebaut und dann hochgepusht und wenn du es aber, und da waren andere Dateien drin als das, was im Repo drin war. Ja, genau. Und interessanterweise war im Paketierten was anderes drin als im Tabor. Genau. Genau, genau. und das willst du ja auch verhindern. Ansonsten machst du das gleiche Problem, weil es ist immer schön, einfach zu sagen, ja, Open Source-Projekte, da kann ja jeder irgendwie was machen. Ja, macht aber keiner, genau. Und dann, wenn du aber auf deinen eigenen Scheiß guckst, merkst du eigentlich so, das ist schlimmer, häufig. Ja. Ja. Ich meine, das, was wir jetzt gerade genannt haben, war ja das meiste aus dem Build-Stage. Aber eigentlich ist das ja sehr stark überlappt mit dem Test-Stage. Quasi auch, weil wir haben ja viel getestet. Deswegen haben wir einmal beim Container-Bauen einen Test, ob es sicher ist, quasi, als auch danach. Gehen wir jetzt nicht doppelt darauf ein, weil theoretisch hast du dann jetzt beides. Oder Test-Reven-Development geben wir jetzt auch nicht drauf ein, sonst wird es, glaube ich, zu weit, oder? Ja, genau. Das ist auch eher Standard, also ein gewisser Standard der Bekannten. auch so ein paar sachen weil wenn wir uns jetzt beim testen mal angucken weil theoretisch kannst du ja kann ja jeder auch eigene pipeline bestandteile bauen da gibt es ja auch noch mal quellen woher ziehst du das container image für den bau wenn. Der bopfe bilder privileges hat ja genau. Genau weil ich das kann es halt auch noch mal was machen ja weil da kannst du halt theoretisch auch gucken dass zu sagen, sagt es, okay, wir bauen jetzt sicheres EICD, Bausteine, die die Teams nutzen müssen, was für viele Sachen halt funktioniert, aber nicht unbedingt für alles, weil Projekte unterschiedlich sind. Wichtig, es sollten Bausteine sein und nicht, wir machen die ganze Pipeline für euch, weil das wird wahrscheinlich nicht funktioniert oder es geht nicht so gut. Und dann kommen wir noch dazu, dass wir da noch sehr, sehr viel, dass das auch nochmal natürlich ein eigenes Team sein kann. Genau. Ein weiterer Punkt ist, dass wir noch das, was auch wieder zum SAST-Scanning halt angeht, noch Infostructures-Code-Scanning auch haben können. Gleiches Prinzip, müssen wir jetzt, glaube ich, nicht tiefer betrachten. Und was dann halt noch wichtig ist, ist, dass wir bei kritischen Schwachstellen, die zum Beispiel vom SaaS oder Infrastructure-Code-Scanning zum Beispiel dann auch kommen, dass wir da auch einen gewissen Guardrail auch haben, so okay, wenn neue World-Rubility drin sind, dass man gar nicht erst weitermachen kann, weil uns bringt das Ganze ja auch nichts. Ja. ja und also ich meine das ist auch noch mal ein punkt generell wie die die die severity die so eine schwachstelle hat die kann ja auch sein dass ich bestimmte severities tatsächlich im endprodukt erlaube ja und aber das wäre dann sache vom cso solche regeln vorzugeben also chief information security officers der der für die sicherheit im unternehmen verantwortlich ist genau. Eigentlich gilt sie für alle punkte die wir genannt haben weil man kann ja auch sagen okay wenn da irgendwie etwas falsch ist, dann wird das erst mal noch reportet und wir gucken hinterher nach, was vielleicht für den Anfang relevant sein könnte, damit wir den Prozess nicht zu blockieren. Aber das sollte dann nach und nach natürlich verschärft werden. Und der letzte Punkt für diesen Teil, und damit sind wir, glaube ich, auch soweit durch, ist Variablen, also Secrets. Du hast ja häufig irgendwelche Secrets im Bild und Test, kommt dafür Deployment erst recht noch mal relevant. Aber du hast dann ja auch noch mal irgendwelche Sequels, um auf irgendwelche Systeme zugreifen zu können, um irgendwelche Pakete zum Beispiel runterzuladen. Müsst natürlich auch richtig gescoped werden, weil es bringt dann halt auch nichts, wenn du die einfach ausgeben kannst. Ja. Und dann siehst du dann halt die Passwörter, die du eigentlich nicht sehen solltest. Oder die credentials. Ja, vor allem die müssen sicher verwahrt werden und aus irgendeinem Secret Management Tool kommen, genau. Genau, weil das in GitLab zum Beispiel ist zum Beispiel auch nicht so geil. da fern wir das lieber sowas wie Hashtag Vault oder einen Fork davon. Wie hieß das nochmal? OpenBow. Wie hieß das? Ja, genau. Willst du eigentlich auch, wenn du es richtig machen willst, weil dann kannst du auch einfacher rotieren. Ja. Und hast es dann auch einfacher, habe ich aber auch keine Erfahrung mit. Ja, aber ich meine, das Grundprinzip ist ja leicht. Man sollte die Secrets unabhängig vom Code und unabhängig von der Pipeline aufbewahren. Da sollte ein Zwischenschritt dazwischen sein, genau. Genau, die Pipeline sollte darauf referenzieren. Genau. Das waren so alle Punkte, die mir eingefallen sind. Wahrscheinlich gibt es da noch ganz, ganz viel mehr. Ich schreibe gerade nämlich einen Artikel für Heise in dem Bereich. Deswegen arbeite ich das gerade so. Und ich habe Schwierigkeiten, gerade das in einem gesunden Maß zu bekommen, dass das nicht ausufernd ist, weil das könnte ein eigenes Buch werden, so in die Richtung. Nicht schon wieder. Nein, nein. Geh weg. Nicht schon wieder ein Buch update. Genau. Genau, was mich jetzt interessieren würde, ist auch, weil ich da natürlich gucke, aus meiner Selbstständigkeit da mal ein bisschen drauf zu gucken. Ich würde gerne da, da bräuchte ich aber vielleicht den einen oder anderen Kontakt, bei Firmen, wo ihr denkt, dass das relevant ist. Ich bin gerade dabei, was zu erarbeiten, um das Ganze halt zumindest erstmal gegen den GitLab, weil da kenne ich mich am besten aus. dass man einmal quasi gegen die API geht und nachschaut, was ist denn alles konfiguriert sodass man quasi einen Audit-Bericht bekommt so, hier solltest du mal rangehen, und das kann dann natürlich dann auch hilfreich sein, oben eine To-Do-Liste zu bekommen Ja. Also ich kenne da tatsächlich nichts aber das war auch alles zu erwarten. Glaube ich Ja, ich meine das Problem ist halt auch weil ich kann das nicht für mich alles testen weil du musst ja auch mal betrachten, es sind nicht für alle Projekte relevant, es ist für einige Projekte relevant, und ich habe halt nur meine zehn Projekte oder so da macht das Ganze nicht so viel Sinn das zu testen Ja. Aber ich vermute sehr, dass da jetzt sich jemand schon Gedanken drüber gemacht hat und dass es solche Tools auch gibt Ja. Ich habe es schon vor ein paar gehört dass es da gibt, aber teilweise auch ein anderer Fokus, Genau. Gut. Prima. Über alles, was wir vergessen haben, erwarten wir Kommentare. So, jetzt habt ihr es. Genau, genau. So, jetzt haben wir noch Medientipps und Tooltipps. Und ich habe ein relativ schnelles Buch-Tipp. Und zwar habe ich das Buch gehört, Psychologie des Geldes. Und fand ich relativ spannend, weil da haben wir dann auch eben, oder habe ich halt auch gemerkt, wie viel eigentlich die Psychologie des Geldes effektiv ausmacht. Weil ganz viele Sachen, was Geld angeht, weißt du eigentlich, was gut oder schlecht ist. Aber das heißt nicht, dass du es unbedingt alles machst. Weil jeder hat sein eigenes Sicherheitsbedürfnis, kannst du gut damit schlafen und das folgt nicht unbedingt immer der Reihenmathematik oder Logik. Ein Beispiel als ich mein Haus finanziert hatte das waren 1,2% Zinsen total wenig ich habe trotzdem Sondertilgung gemacht weil ich die Zahl runter haben wollte, witzigerweise hatte ich damals weniger Einkommen als später dann habe ich es aufgehört, einfach nur weil ich die Zahl weniger haben wollte ich wusste, dass es eigentlich nicht so viel Sinn macht bei den Zinsen habe es trotzdem gemacht einfach nur um ruhiger schlafen zu können, und das Buch fand ich in dem Sinn halt spannend, weil es halt sehr, sehr oft dann Beispiele genannt hat, wo man solche Sachen dann halt eben rausgelesen, wo man dann erst auch merkt und man hat sie doch selbst wieder gefunden in den Sachen, da geht es auch so Sachen wie Zinses, Zins, weil eigentlich kennt jeder die Theorie, trotzdem machst du was falsch. Oder kriegst du in Panik, wenn, keine Ahnung, der Aktienmarkt einbricht oder sonst was. Oder du denkst, du bist total arm, aber dabei hast du ein Haus in hohem Wert. Das sind alles so Punkte, die da so mit reinspielen. Fand ich ein recht spannendes Buch. Kann man sich lesen, kann man sich anhören. Vor allem hat das ja auch oft mit gefühlten Reichtum zu tun, oder? Ja, genau. Oder gefühlter Armut. Man sucht sich ja immer Beispiele, an denen man sich abarbeiten kann. und man findet immer Leute, die reicher sind. Ja, genau. Ja, außer Elon Musk. Wobei, der wurde doch jetzt auch überholt von dem Oracle-Typen. Larry Allison, aber ja. Genau. Ist ja auch ein Unterschied zwischen reich sein und reich aussehen. Ja, ja, ja. Ich enthalte mich eines Kommentars. Halsabschneider, Elende. Jetzt habe ich es doch kommentiert, tut mir leid. Genau. Gut. Soviel zu meinem Medientipp. Ich glaube, ich werde das mal lesen. Ich habe einen Medientipp, den ich von Stöpfs habe. Da geht es aus der Mediathek, aus der ZEF-Mediathek. Ich weiß gar nicht, bis wann das gespeichert ist. Da geht es um Trump und das Silicon Valley. Und da geht es darum, dass die Internetgrößen, Internetmogule versuchen, an der Demokratie vorbei, weil Demokratie ja viel zu langsam ist, an der Demokratie vorbei Politik zu treiben. und damit auch im Prinzip die Trump-Administration unterminieren. Hochinteressant, also viele Dinge kannte ich schon. Einige Sachen waren mir komplett neu. Einfach zu sehen, dass das die Leute sind, die eigentlich das komplette Land steuern, ohne dass sie eigentlich eine demokratische Befugnis haben und die das auf eine dermaßen subtile und gefährliche Art und Weise machen, dass es kaum noch nachvollziehbar ist. Ja, muss ich mir, glaube ich, auch angucken. Wie lange ist das eigentlich? Eine Dreiviertelstunde, also jetzt wirklich nicht so viel. Ja, okay. Aber das ist erschreckend. Gute Dokumentation ist erschreckend, wirklich. Ja, es ist Nightmare online. Ja, das hat mich auch neulich dran gedacht, als alle der Tech-Leader quasi bei Trump vor ein paar Tagen oder ein paar Wochen zu Besuch waren und sich bedankt haben für die mögliche Sorge. Also ich arschkrieche mich. Die Kniefälle vor dem Autokarten machen, das ist für mich sowieso eine Sache, die irgendwie gar nicht gehen. Ja, genau. Und wenn dann der Nächste kommt, egal in welche Richtung, dann wird wieder alles dahin gelingt. Also Hauptsache, dass Geld fließt. Ja, furchtbar. Ja, es ist frustrierend eigentlich sogar. Ja, frustrierend und wirklich schlimm. Ja, das auch. Könnte ich mich jetzt lange drüber aufregen, ehrlicherweise. Aber lassen wir es besser. Ja, lass uns lieber zum nächsten Two-Tip gehen. Ja, mach mal deinen Two-Tip. Das tut nämlich was dagegen. Und zwar habe ich eigentlich schon vor der FrostCon, aber bei der FrostCon gab es einen Stand von Newpipe. Ich habe mir das nicht angeguckt, aber das hat mich nochmal erinnert, dass ich da mal drauf gucken wollte. Es ist ein leichtgewichtiger YouTube-Client für Android, der Open-Source ist, wo ein Ad-Blocker mit drin ist, wo du Videos zum Offline angucken kannst, wo Privacy-mäßig quasi nur das Nötigste macht, um die Videos zu laden und abzuspielen. Du hast sowas wie einen Background-Player drin oder auch einen Pop-Up-Player. Und du kannst auch Kanäle abonnieren, ähm, Ohne, dass es halt irgendwie mit deinem YouTube-Account verknüpft ist. Ah, okay, cool. Das ist natürlich nicht im Play Store, weil das findet Google nicht so toll. Du kannst es einfach als APK-Site loeren. Im F-Droid ist das drin. Das funktioniert auf dem Handy und dadurch hast du halt diese ganze Werbung nicht mehr drin. Das ist der wesentliche Vorteil. Ja, sehr cool. Und das unterstützt halt nicht nur YouTube, sondern auch Peertube, Soundcloud, Bandcamp und MediaCCC.de. und dann hast du dann so einen nativen Player quasi da drin. Das ist recht praktisch. Ja, wobei ich sagen muss, media.ccc.de, da lade ich die Videos runter und lade die bei Pocket Casts hoch und gucke die da mit. Weil dann kann ich da aufhören und an irgendeiner anderen Stelle mit einem anderen Gerät einfach weitergucken. Aber für YouTube ist das sicherlich ein super Tipp, glaube ich. Ja, für die anderen Sachen auch, wenn man es braucht, ja. Wenn man es braucht, ja. Na klar, wenn man es braucht. Also ich habe keinen Peertube, keinen Soundcloud, Bandcamp, keine Ahnung, kenne ich nicht. Ich auch nicht, ja. Aber es ist praktisch, um... Also man kann auch dann, gibt es aber auch eine Anleitung zu, wenn man in der App ist, wie man bei YouTube, beziehungsweise Google, die Abos runterladen kann. Ja. Also eine CSV ist das, glaube ich, oder eine JSON. Und dann kannst du die in die App wieder laden und dann hast du deine Subscriptions quasi einmal übernommen. Das ist sehr cool, ja. Genau. Ist dann halt nicht synchronisiert, sondern One-Way, aber passt ja. Ja, ich habe einen Tipp, ich versuche gerade von, oder ich wechsle gerade von LiquidPompt auf Starship heißt es, Spaceship war das andere, auf Starship als Prompt und bin dabei über, also Starship selber kann ich noch nicht empfehlen, weil ich noch nicht viel Erfahrung habe, aber ich bin dabei über Nerdfonds gestolpert. Nerdfonds sind normale Programmerfonds, die um Icons erweitert werden, wo man Icons für jeden Scheiß findet, letzten Endes auch für alle möglichen Hersteller Software- und Betriebssystem-Logos zum Beispiel. Und die dann einfach im Font eingebaut sind und damit auch auf dem Prompt ausgegeben werden können. Das ist so der Zusammenhang dazu. Und ich kannte Nerdfonds vorher gar nicht. Es gibt zu fast jedem Font mittlerweile Nerdfond. Und es gibt eine Webseite, programmingfonds.org, wo man sich die ganzen Fonts angucken kann. Ich habe es gerade mal aufgemacht. Ich kenne keinen, der hat ja zum Beispiel die Icons von Font Awesome drin. Ja. Aber halt nicht nur, das ist ja nur ein kleiner Teil der Font. Ja, genau. Weil das kannte ich zum Beispiel. Das ist spannend, ja. Ich benutze für mein Terminal zum Beispiel den Hack-Font. Ja, den habe ich schon mal von gehört. Ja, und den Hack-Font gibt es auch als Nerd-Font, wo dann eben die ganzen Icons drin sind, als Beispiel. Also ich müsste noch nicht mal auf meinen präferierten Font verzichten, sondern kann einfach den Font runterladen und um Icons erweiterten Font benutzen. Ah ja, aber wie installierst du das dann genau? Das ist ein normaler Font, den kannst du runterladen und einfach in deinem Betriebssystem als Font installieren. Also einfach aufs File-System packen dann, wo es installiert wird? Ja, genau. Also jetzt nicht als Paket? Nein, das ist ein zip-File, wo, glaube ich, TTF-Dateien drin sind, also diese TrueType-Fonts und die kannst du ja in deiner Desktop-Umgebung ganz normal als Fonts installieren. Ja, okay. Ja, Paket wäre irgendwie schöner, aber gut, so ist das manchmal. Ja, gibt's vielleicht auch einige als Paket, aber ich hab jetzt, so tief bin ich jetzt noch nicht eingetaucht, ehrlicherweise. Okay, kann sein, dass es auch gibt. Ja, ist definitiv gut möglich, ja. Ja, es gibt ein Von-Patcher-Skript, damit kannst du dann, glaube ich, auch die häufiger aktualisieren oder sowas. Ja. Cool. Gut. Dann sind wir fertig, glaube ich. Ich glaube auch. Dann empfehlt uns weiter, gibt uns Feedback unter tilpod.net findet man Feedback-Kanäle von uns, kommt in die Matrix-Gruppe. Da war in den letzten Tagen richtig viel los, da kommt man kaum noch hinterher. Genau, aber es macht Spaß, genau. Genau, ich wurde schon darauf kritisiert, dass ich eine ordentliche Programmiersprache lernen soll. Vielleicht gab es doch wieder Krieg, was besser ist. Ich finde, es ist sehr gesittet abgelaufen. Ja, natürlich. Alles gut soweit. Ich habe alles ignoriert. Nein. Ja. Gut. Okay. In dem Sinne. Schönen Abend. Bis zum nächsten Mal. Tschüss. Tschüss.