Secrets Not Included: Policies

Willkommen zurück zu Secrets Not Included, wieder mit Daniel und Ole hier.

Vielen Dank.

Und in dieser Woche möchten wir mit euch über Policies reden. Ich glaube, wir haben vor zwei oder drei Wochen das schon mal kurz angeschnitten, dass es da etwas gibt, was man nutzen kann, um ganz verschiedene Systeme abzusichern und zu prüfen, ob bestimmte Voraussetzungen eingehalten sind. Und jetzt wollen wir diese Woche einfach etwas tiefer damit eingehen, reingehen mit euch. Und zwar in ein Tool, das nennt sich Open Policy Agent. Das ist ein offizielles Projekt der Cloud Native Compute Foundation und nutzt eine eigene Policy Language, die Rego heißt. Rego hatte ich da ja auch schon erwähnt. Und ja, Daniel, ich glaube, du hattest letztes Mal Fragen dazu.

Ganz viele, ich habe die immer noch. Ich muss ehrlich sagen... Oh, das ist schlimm, das kenne ich.

Ich hoffe, ich habe heute alle Antworten mit, nachdem ich mich auch wieder daran erinnere, wie wir das machen und mit welchem Tool.

Dieses mit, es ist erledigt, Klick, Häkchen dran und aus dem Gehirn raus.

Ja, und wenn was ist, dann kann man ja nochmal, dann steht es in der Doku, was es war.

Ja, genau.

Hervorragend. Es ist in der Pipeline drin, in unseren Makefiles überall drin, wird ausgeführt.

Also wir hatten über Policies gesprochen. Das Grundkonzept oder die Grundidee finde ich sehr interessant, dass man sagt, es gibt gewisse grundsätzliche Regeln. Fehler machen darf jeder, aber so Fehler zweimal, dreimal, viermal machen wird halt irgendwann peinlich. Gerade auch beim Kunden und das ist ja so der Grundgedanke gewesen, warum man angefangen hat zu testen. Man hat ja dann, oder meistens ist es so in einem Projekt mit, okay, es knallt, es geht irgendwas kaputt.

Mhm.

Ich als Entwickler sage, hm, habe ich nicht gesehen, aber ich baue den Test mit dem Fix zusammen, deploye das. Jetzt hast du von Policies gesprochen und das erzeugt bei mir natürlich eine Erwartungshaltung, dass ich sagen kann, guck mal, da könnte es etwas geben, wo ich mir Sachen zusammenbaue, Regeln zusammenbaue, auch jetzt nicht so konkret auf Business-Logik, die ein Projekt betrifft, aber wo man sagen könnte, es gibt immer wiederkehrende Fehler. Zum Beispiel, das weiß ich nicht, irgendwo Credentials landen, wo sie nicht hingehören, also eine.env-Datei, weil viele mittlerweile Angst haben, die zu committen, weil da jetzt Produktiv-Credentials drin landen oder so.

Und

keine Ahnung, solche Sachen. Das triggert bei mir so etwas, wo ich sage, man könnte sich da einen Regelsatz aufbauen, um einfach, den man auch gerne teilt. Also wenn ich mal irgendwann einen habe, teile ich den gerne. Wo man sagt, das ist so ein Grundsetup mit, die Fehler hat schon mal jemand gemacht oder das ist schon mal schief gegangen. Ich bin safe, also zumindest was das betrifft, safe.

Ja, ich sag mal jetzt mal, das ist bei uns eine Mischung aus Komfort und es ist nervig, wenn man immer aufs gleiche Knie fällt, ne?

Ist auch ein cooler Spruch, ja.

Also ich sag jetzt mal, wenn ich so an unsere Composer-Regeln denke, schauen wir da zum Beispiel, ist der Package-Key in der Form, wie wir ihn haben wollen oder auch für Typo3-Pakete, ist denn dieser Extension-Key da drin gesetzt? Ja, ja.

Achso, das ist wichtig für Typo 3. Das ist doch dann irgendwas mit Null-Pointer.

Ja, sonst kommt das System nicht damit klar. Wenn dieser Extension Key fehlt, dann findet Typo3 das duft. Das ist eine Regel, dass er halt da sein muss. Und bevor man in diese komischen Fehler läuft, die das System dann schmeißt, weil es sagt dann ja nicht, hey, der Extension Key fehlt in dem Paket, das aber sagt, es ist ein Typo3-Paket, sondern du hast dann komische Fehlermeldungen und Seiteneffekte. zumindest bis zum Zeitpunkt, wo wir diese Regel eingeführt haben, vielleicht ist es jetzt heute anders, nur wir laufen gar nicht mehr in dieses Sky, weil wir jetzt diese Regel da haben, ja, dann stand über mein Haupt, dass ich diesen Fehler wegen der Regel nicht mehr gemacht habe und jetzt ist alles voll super und das sagt mir, da fehlt der Extension Key.

Ja, ja.

Aber ich sage jetzt mal, ich bin ja nicht so lernfähig, immer morgens um vier oder so, wenn ich eine heiße Idee habe und anfange, was zu bauen. vergessen. Aber wir haben auch andere Regeln, zum Beispiel, dass die PHP-Version drinnen stehen muss. Aus dem einfachen Gedanken, wenn wir nämlich Container bauen, schauen wir nämlich nach, hey, in dem Hauptprojekt, welche PHP-Version brauchen wir denn da?

Oder wenn es leer wäre, nicht, ne?

Und das haben wir in der Composer JSON gepflegt, weil sich dann unser Container quasi automatisch die richtige PHP-Version sieht, beziehungsweise unser Docker Setup halt auch lokal die richtige PHP-Version dann wieder bekommt. Ja, also es ist halt total simpel, weil du dann halt über Variablen sehr flexibel und sehr zügig unterwegs bist mit dem Standard Setup. Umso wichtiger ist natürlich, dass bestimmte Voraussetzungen für dich eingehalten sind. Was wir auch noch machen, ist halt, wir prüfen halt dort Enddateien logischerweise, ob da so etwas drin steht wie Password, Secret, Key.

Aber der...

Und ich glaube noch ein paar andere Dinge, die ich jetzt wieder mal nicht auswendig weiß. Was steht da? Ich kann es auf die Entfernung nicht lesen. Ist zu klein. Auf jeden Fall auch so Sachen, wenn irgendwo 1, 2, 3, 4 steht als Wert für irgendwas, dann finden wir das auch nicht cool. Und dann sagen wir, na, sorry, not sorry, hier ist jetzt mal Schluss damit. weil auch wenn wir.env-Dateien ja grundsätzlich nicht so mögen, haben wir halt trotzdem.env-Dateien.

Ja.

Da sollen halt nur keine Secrets rein. Die sollen bei uns, wenn sie denn existieren, eine Secrets.env, wo nur verschlüsselte Werte drin sind. Da, wo wir SOPs einsetzen, ist das quasi der Weg, Und dann prüfen wir halt entsprechend, sind dann alle Sachen, wo Secrets so von der Benahmung typischerweise drin wären, sind sie denn nur in der Datei und sind dann nur verschlüsselte Werte drin.

Ja, je nachdem, welchen Algorithmus ich habe. Mhm.

Du kannst ja nicht dann auch wieder sagen, okay, du weißt ja, womit der verschlüsselte String anfangen muss. Genau. Und da prüfen wir dann drauf. Und was wir auch machen, ist, wir prüfen zum Beispiel, ob Lizenzen eingehalten werden. Wenn du Open-Source-Pakete einsetzt, musst du natürlich darauf achten, oder solltest du eigentlich darauf achten, dass die Lizenzen, die du einsetzt, kompatibel sind und dass die Lizenzen, die du in deinem Produkt drin hast, in deiner Plattform drin hast, auch zu dem Zweck passen.

Ja. Ja.

Wenn du natürlich ein Paket ziehst, wo eine Lizenz drin ist, die sagt, naja, Commercial Use ist nicht erlaubt, erlaubt, wäre das für die meisten Projekte, die wir so haben, nicht unbedingt zuträglich. um das jetzt vorsichtig auszudrücken. Also das heißt, wir prüfen zum Beispiel darauf, ist da eine MIT oder Apache 2.0 oder ähnliche Lizenzen, GPL, in der entsprechenden Version drin, damit wir das ohne Probleme einsetzen können. Und sonst muss man sich halt Alternativen suchen, ehrlicherweise.

Und das geht dann so, dass der automatisch auch neue Pakete oder neue Abhängigkeiten mitprüft?

Ja, das kommt natürlich darauf an, wie du deine Regeln schreibst, ob das dann automatisch so klappt, aber wenn du halt sagst, okay, ich prüfe zum Beispiel die Package-JSON und die Composer-JSON, dann hast du zumindest einen guten Indikator dafür.

Also das... Mhm.

Eigentlich musst du so Tools benutzen wie SPDX oder ähnliches, Lizenz-Scanner, die tatsächlich Datei für Datei durchgehen. und da prüfen, was aber auch wieder zur Folge hat, dass du eigentlich in jeder Datei einen entsprechenden Eintrag haben musst oder eine Begleitdatei mit der Lizenz, weil die Lizenzscanner das sonst nicht sauber unterscheiden können und dann kommst du nämlich in das Problem, dass du sehr, sehr viele Unbekannte hast, die du manuell prüfen musst.

Ja, das ist halt keine Hilfe. Aber das heißt ja eigentlich, dass sozusagen die Leute, die ihre Pakete pflegen und Open Source stellen, in der Composer JSON hoffentlich alle richtig, die Lizenz eintragen. Und da würde ich mich auch darauf verlassen.

Ja.

Also erst mal, wenn es da Abweichungen gibt, ja, dann ist das halt, also ist das nicht so. Ist auch doof, aber mir wird das reichen für den Test, um mich darauf zu verlassen, zu sagen, guck mal, das Paket behauptet selber, es hat diese Lizenz. Wenn die sich jetzt da umentscheiden oder das irgendwann ändern, dann müssen die das da eintragen. Und ich denke mal, das werden auch 99 Prozent der Leute machen, wenn sie es nicht vergessen.

Ja, könnte sein, aus Erfahrung mit solchen Compliance-Prüfungen kann ich dir sagen, dass selbst große Open-Source-Pakete dich anlügen und nicht sauber die verwendeten Lizenzen deklarieren.

Echt? Hm. Hm. Hm.

Ja, dann gibt es dann irgendwo eine Binary oder ähnliches, nochmal tief vergraben, die aus einem anderen Paket kommt und eigentlich eine andere Lizenz hat. Und das kann natürlich dann auf einmal kritisch werden, wenn das dann nicht kompatibel ist. Ja.

Ja, genau, genau. Dass die Unterabhängigkeit sagt, dass es nicht kommerziell genutzt werden darf. Da hat jemand gepennt, hat die eingebunden und du bündest dann, oh Mann. Ja, ja.

So, und Compliance-rechtlich, ja, für alle Papiertiger da draußen, ist das natürlich ein riesiges Thema und ein Problem ist das auch lizenzrechtlich, ja, rein rechtlich betrachtet ist das natürlich total kritisch und verstößt halt gegen die Lizenzierung und die Bedingungen. Jetzt sage ich aber im Alltag, wir müssen halt irgendwo die Kirche im Dorf lassen, das heißt, ich muss mich zu einem gewissen Teil darauf verlassen können, Und mit dieser Regel prüfe ich zumindest mal, ob die Deklaration des Pakets so ist, dass ich davon ausgehen kann, dass alles richtig ist.

Ja.

und muss nicht tausende Dateien, die keine saubere Deklarierung hatten, manuell durchgehen und prüfen. Das ist dann etwas, das muss dann halt in Projekten speziell geprüft werden und speziell gemacht werden. Das kann man dann halt nicht vollumfänglich automatisiert machen. Und das Schöne ist an diesem OPA, einem Open Policy Agent, dass du halt über die Tools hinweg prüfen kannst. Du kannst halt nicht nur sagen, ich prüfe meine Composer JSON oder meine Package JSON oder jetzt irgendwelche PHP-Dateien, ob da jetzt Lizenzen drinstehen,

Ja. Alles über 1024.

Sondern du kannst halt auch deine Dockerfiles prüfen, ob da jetzt ein Expose auf 80 stattfindet. Oder du kannst halt auch Infrastruktur, Terraform-Sachen prüfen, ob da irgendwelche Einträge drin sind, die du nicht haben möchtest. Wenn du zum Beispiel in einem OpenShift unterwegs bist, dass du nur Highport Expost, also sprich kein 80, kein 443, sondern halt irgendwo, ja, Und damit kannst du halt sehr effektiv, sehr schnell prüfen, unabhängig von irgendeiner Programmier- oder deklarativen Sprache, die du einsetzt.

Hmm. Hmm.

sondern halt nur mit Rego als Sprache, die dann halt Policies insgesamt abbildet und dir die Sicherheit gibt, dass du es zum einen natürlich lokal ausführen kannst und prüfen in der Pipeline prüfen kannst und bestimmt auch noch an unterschiedlichen anderen Stellen das als Regeln einsetzt. sodass du halt auch prüfen kannst, zum Beispiel wird immer vom root-user weggewechselt, ja, habe ich tatsächlich rootless-container, nicht nur mir ausgedacht, sondern sind die auch tatsächlich rootless-dich-einsätze.

Ja.

Hat nicht jemand diese Regel entfernt am Tagesende?

Ja, oder aus Versehen auskommentiert. Also ich muss ja zugeben, ich schaffe das auch immer wieder beim Entwickeln gerade mit, ich mache da kurz mal was weg und irgendwie zwei oder drei Ablankungen später weiß ich das nicht mehr. Und dann sind Sachen auskommentiert.

Ja, genau.

Mhm.

Gerade wenn ja die Container, die lokal laufen, die gleichen sind, die in Produktion laufen. Wovon ich ein großer Fan bin. So rein Debug-technisch und Fehleranfälligkeitsmäßig finde ich das immer sehr, sehr sympathisch, wenn ich quasi meinen Produktiv-Container habe und dann nochmal obendrauf eine Layer packe für Development mit DevTools. Ähm, natürlich, wenn du dann den falschen Layer manipulierst oder manipulieren musst, weil irgendwas alles ist ganz seltsam. Ähm, ja, manchmal ist es ja so, ne?

Ich lache, weil ich das schon bestimmt zehnmal gemacht habe. Also nicht, weil ich besser bin, sondern weil das genau das ist, was ich auch mache. Also...

Irgendwie wird, dann muss man doch mal Ruth sein. Und dann, ne, so. Ähm. Und man macht sich dann auch mal einfach Sachen kaputt. Und damit man das dann halt wenigstens nachher nicht im Endergebnis drin hat im Repo, ist es natürlich total cool, wenn man die Regel hat, die einem sagt, jung, jetzt musst du noch mal ran. Den Commit nehmen wir jetzt nicht an.

Mm.

Und so sehe ich ja auch die Pipeline immer. Meine Pipelines laufen ja immer von möglichst schnell und kosteneffektiv zu den teureren. Also je früher es kaputt geht und sagt, da hast du aber Unfug gemacht. je besser ist das, je schneller das geht. Weil wenn am Ende es mir dann sagt, ja, aber jetzt, ich habe alles gebaut und jetzt stelle ich fest, du bist ja, dein Dockerfile ist ja auf einmal mit Hut. Ja, danke, das wäre ein Fix von einer Sekunde gewesen gefühlt. Also mach diese Regel mal zuerst und dann für bitte erst die Unit-Tests und so weiter und so fort aus.

Ja, also ich finde das interessant. Zumindest, dass man, wenn ich es richtig verstanden habe, es gibt unterschiedliche Clients, glaube ich, womit man zum Beispiel auch JSON und andere Sachen lesen kann.

Ja, ich weiß nicht, ob das jetzt Client heißt, aber ja, es gibt, ja.

Und dann... ich habe es gerade so genannt, also Implementierung, keine Ahnung, was es ist. Also die Möglichkeit, JSON-Dateien zu lesen oder JSON zu lesen und da auch darauf zu antworten oder beziehungsweise zu testen. Aber das basiert alles darauf, dass ich Regex eigentlich schreibe und sage, das ist das Ergebnis, ein Result-Set, wie auch immer, und darauf teste ich dann ein Regex.

Ja, nicht immer direkt ein komplettes Regex. Du hast auch so Sachen, wo du sagen kannst, okay, jetzt der Anfang muss sein oder das Ende muss sein oder etwas muss lowercase sein oder uppercase und so. Aber du kannst natürlich auch immer sagen, okay, Regex match und dann schreib dein Regex tag ein.

Also man kann es entweder lesbar machen oder mit Regex machen.

Was war denn jetzt das Rek-Ax-Bashing? Also ich mag Rek-Ax, also Rek-Ax hat mir echt schon manchen Tag gerettet.

Und zehn Minuten später wusste ich nicht, was ich geschrieben habe. Ja. Ja, genau. Ja.

Also wer es nicht kennt, Rek-Ax 101... die Seite für Regex schreiben. Ja, natürlich. Manchmal verbringt man da zwei Stunden oder zumindest früher mal zwei Stunden, um das Regex, das beste Regex der Welt zu schreiben. Dass man nach der Mittagspause auch, keine Ahnung, aber es funktionierte. Ja, aber das ist halt bei Regex so. Es ist

Es ist super mächtig. Ich mag es sehr und ich kenne meine Schwäche. Ich übertreibe es gerne damit. Deswegen lache ich gerne darüber, dass man es entweder lesbar hat oder in Regex, weil irgendwann wird es einfach unlesbar. Wenn man das auseinandergefilmt hat, ist es aber super hilfreich manchmal, was man da unterbringen kann.

Ja, natürlich. Aber du kannst in Rego nicht nur Regex nutzen. Du kannst auch so Sachen sagen wie Not is empty und so. Also ganz leserlich und einfach starten mit Regeln, schön immer in einzelner Dateien strukturieren.

Aber das Grundkonzept, wenn ich das richtig verstehe, ist es, ich schreibe eine Reko-Datei, wo ich Annahmen treffe und sage, ich möchte, dass etwas Text enthält, nicht enthält, so formatiert ist, groß, kleinschreibt, also irgendwelche Regeln, kann dann sagen, das soll in dieser, dieser oder dieser Datei sein oder passieren oder enthalten sein.

Ja. Ja. Mehr Magie ist das gar nicht. Also...

Und das war's. Oder, also, dafür, Das ist viel zu einfach. Kann das nicht mehr Magie sein? Mhm.

Ich glaube, du kannst es auch auf unterschiedlichen Umgebungen ausführen. Das machen wir jetzt zum Beispiel nicht. Da kann ich jetzt nicht so richtig weiterhelfen. Ich weiß, dass es auch in Kubernetes und Istio und so weiter läuft. Und da bestimmt auch noch super fancy Sachen macht, die wir jetzt nicht so im Einsatz haben. Aber wie es immer ist, irgendwo fängt man an, dann entdeckt man mehr Use Cases dafür, dann verwendet man das auf anderen Stellen. Wir prüfen zum Beispiel auch, ob unsere Pipeline-Components entsprechend geschrieben sind und so Sachen, dass da bestimmte Sachen einfach drin sind. Ich sage ja, man entdeckt halt immer mehr Möglichkeiten, wo man es einsetzen kann. Je häufiger man irgendwo aufs Knie fällt und sagt, ach, das war jetzt aber mal wieder so ein richtig dummer Fehler, der überflüssig ist. Ja.

Ja genau, also dieses Projektunabhängige gefällt mir sehr. Also dass man, ne, weil alles was mit Tests, Unitests, Applikation, also alles was irgendwie testbar ist, ist immer projektspezifisch. das kann man schwer mitnehmen, sage ich mal, wo man sagt, das ist und oder unternehmensweit einführen für, ne, wenn du eine Agentur hast oder irgendwo ein großes Unternehmen und zig Projekte hast, kannst du ja schlecht irgendwie Unit-Tests von A nach B kopieren, also gibt es bestimmt auch, ne, dass du sich ein Test hier bildet.

ja, da sind die Unit-Tests halt auch das falsche Mittel. Die Unit-Tests oder viele Testing-Sachen sind ja, ich sag mal, paketspezifisch. Und damit kannst du halt ein allgemeines Set an Policies, an Regeln haben und verwenden. Und das finde ich mega gut. Das bedeutet halt, ich kann halt immer sagen, okay, pass auf, meine Enddatei, so, das möchte ich halt haben.

Kannst du mal wieder auf die Finger hauen.

Und das Schöne ist, damit erwischst du natürlich auch deinen KI-Agenten am Tagesende wieder, wenn er Schmuh macht. Ja, der vergisst natürlich gerne, QS-Tools auszuführen zum Beispiel. Ja, PHP-Stand, keine Ahnung, findet der mega ätzend, weil der natürlich immer die Fehler direkt aufdeckt. Bei mir fängt der auch gerne an, dann zu meckern und zu sagen, ne, ne, ne, da sind schon wieder Fehler, aber die waren vorher schon da, das war ich gar nicht.

Ja, ja, genau. Wie so ein Fünfjähriger, das war ich nicht. Mhm.

Ja, so, und das ist natürlich immer so mega ätzend. Also, ganz ehrlich, ich erwarte, wenn ich der KI sage, hey, fix jetzt mal diese Fehler, da bitte mich interessiert diese Ausrede nicht mit, nee, die gab es schon vorher, mich interessiert nur, dass die Fehler weg sind. Und wenn ich ein Tool habe, das halt blockiert und sagt, hier, da ist was falsch, dann kann die KI halt auch direkt darauf reagieren, indem ich sage, ja, jetzt, schau mal, wir haben das jetzt ausgeführt, das Tool, was du nicht machen wolltest. Und die QS sagt jetzt halt, ist scheiße.

Hmm. Hmm.

Jetzt beheb mal die Fehler, die hier drin stehen. Ist mir egal, dass du sagst, du hast sie nicht gemacht, interessiert mich alles nicht, beheb einfach nur die Fehler. Das ist ja genauso mit überall. Ich sage jetzt mal, mich interessiert nie, wer einen Fehler gemacht hat oder wie dieser Fehler entstanden ist, sondern mich interessiert immer am Tagesende die Lösung und dass wir einen Fehler nicht häufiger machen. Ja, wenn man jetzt einen Fehler zweimal gemacht hat, spätestens dann sollte man sich überlegen, wie stellen wir denn ab, dass es den wieder gibt.

Ich habe auch keine Lust, einfach mehrfach zu erklären, dass es immer das Gleiche war. Tut mir leid, ich habe wieder nicht aufgepasst, das.

Ja, sorry, ich hatte noch nicht genug Kaffee.

Hasse ich, wie die Pest, so etwas zu sagen. Ja, genau. Und also auf der anderen Seite, E-Commerce-Kontext zum Beispiel, kannst du den Kunden auch nicht erklären, dass alle drei Tage irgendwie das System weg ist, wenn die irgendwas auf ihre Wunschliste packen oder irgendwie eine komische Klickreinfolge nutzen und damit den Shop kaputt machen oder so, weil dann irgendwelche Abhängigkeiten in Datenbanken kaputt gehen. Ja.

Ja, oder dass ein Jobimport einfach mal zwei Wochen nicht funktioniert, weil man wieder mal was versemmelt hat oder dass Kontaktformulare nicht funktionieren oder Newsletter oder so, weil halt wieder irgendein, wenn man wieder den gleichen Fehler drin hatte oder einfach wieder auch Daten nicht richtig rübergekommen sind.

Hmm. Hmm.

Das kannst du jetzt nicht damit validieren, aber dafür, das kann man ja auch abfangen, wenn man das erkennt.

Ja, aber das ist ja auch wieder ein Baustein für das ganze Paket, sage ich mal.

Und

Genauso wie Unit-Tests, Applikationstests oder Integrationstests und Applikationstests ihre Berechtigung und ganz andere Ziele haben, finde ich das mit den Policies gar nicht mal falsch, weil das ist halt wieder ein Teil, den die anderen drei jetzt nicht abdecken, wo du sagen kannst, das ist halt wieder ein Stückchen besser.

Und ich finde, es ist halt auch eigentlich eine mega hilfreiche Policy und ich finde es immer peinlich, wenn andere Dienstleister das nicht auf die Kette kriegen, wenn sie Sachen übernehmen.

Am besten so im CC-Benz.

dass dann mal keine alten E-Mail-Adressen da mehr drinstehen. Ja, weil ich kann ja super leicht darauf filtern, ist diese Domain jetzt in einem Kontext eines Kommentars oder ist das eine scharfe Adresse, wo Sachen hingeschickt werden. Das ist nämlich immer total cool, finde ich, wenn dann ein Dienstleister was übernimmt, man Sachen abgibt, whatever.

Vielen Dank.

Und dann bekommt man auf einmal Monate später tausende Fehler-E-Mails von einem System geschickt, weil mal wieder jemand vercheckt hat, ganz einfach diese Konfiguration zu ändern. Oder auch so was wie so ein Sentry, dann auf einmal Fehlermeldungen von so einem URL-System auf einmal geschickt bekommt oder error-tracking in GitLab, weil man einfach diese Einträge nicht ändert.

Ja.

Und wir haben zum Beispiel auch dann halt Regeln, die prüfen, jetzt sind alle scharfen E-Mail-Adressen denn von uns. So, ja. Und gibt es so was wie diese DSN, wo Fehler hingeschickt werden? Und wenn ja, stimmt denn die Domain mit der erwarteten Domain überein?

Ja, das ist natürlich geil, wenn du eine Agentur hast und dann kannst du sowas mitnehmen und dann, wenn du ein neues Projekt mitnimmst, lässt du es einfach drüber laufen und da muss sich kein Entwickler wieder drei Stunden hinsetzen und per Grab irgendwie sich dadurch einen frischen Quelltext begraben. Das spart Zeit.

Ja, so. Also, macht dich halt als neuen Dienstleister total glücklich. Ja, weil, weil halt du auch professioneller auftreten kannst und nicht irgendwie der alte Dienstleister da ständig ankommt und sagt, ey, Freunde, ihr schickt uns immer noch Fehlermeldungen, was soll der Scheiß?

Mhm. Mhm.

Na? Und du stellst halt auch sicher, dass du halt direkt alles bekommst. Wie fantastisch ist das denn, wenn du quasi deinem Kunden zeigst, hey, ich kann das auch, was ich tue? Ja, so, aber aus der Erfahrung heraus kann ich sagen, das ist nicht die Masche, die alle Dienstleister fahren.

Das ist natürlich schade, weil alleine die Zeit, die du dir sparst mit solchen Sachen. Also ich denke mal, der erste Wurf wird gar nicht so besonders sein, wenn man mit sowas anfängt, aber ich glaube, über die Jahre oder über das Jahr, dass man da echt ein gutes Regelset aufgebaut bekommt.

Ja, und du musst es halt nicht direkt in LMM schmeißen, also du musst es nicht in die KI schmeißen, sondern du kannst halt echt Low-Level mit wenig Energieeinsatz sehr, sehr viel erreichen.

Hängt halt ein bisschen davon... Hm.

Klar, die KI kannst du nutzen, um dir fremden Quellcode erklären zu lassen und so weiter und so fort.

Ja. Ja.

Da kannst du auch sicherlich sagen, sind da irgendwelche E-Mail-Adressen noch drin geschenkt? Das geht alles. Ja, wer KI dafür nutzen will, go for it. Das ist halt quasi die umweltfreundliche Alternative.

Green Coding, ja.

Ja, man könnte ja darüber nachdenken, dass es cool ist, wenig Energie für so Aufgaben einzusetzen.

Ich würde einfach nicht so viele Tokens verschwenden wollen dafür. Ich verbrauche die für andere Sachen. Also das ist in meinen Augen verschwendet, weil für andere Sachen sind sie definitiv sinnvoller eingesetzt einfach.

Ja, natürlich, aber auch das

Und gerade wenn andere in Tropic und so anfangen, die zu beschränken und versuchen, so die außerhalb der Zeiten dich zu motivieren, die Modelle zu nutzen, dann merkst du schon, wo die Reise hingehen wird in Zukunft.

ja immer schon zwischen Mitternacht und 6 Uhr arbeiten.

Mhm. Da merkst du, wo die Reise in Zukunft hingehen wird. Also das ist natürlich, dass die Token, die müssen entweder besser werden, die Modelle, dass das günstiger für Entropic und andere wird, oder es wird teurer. Und bei weitem ist Geld.

Nee, die Frage ist halt, möchte man nicht eh auf ganz andere Modelle wechseln, ne?

Mhm.

So ein Modell, das ich gerade teste, schleifen wir total ab, aber macht nix. Das ist Gamma 4. Ja, ich finde, das ist extrem vielversprechend und ich bin auch immer noch ein großer Fan von DevStral, von europäischen Modellen allgemein.

Hoffentlich.

Ich finde, der Unterschied ist nicht so groß, dass man jetzt sagen müsste, ich muss unbedingt Cloud Code nutzen.

Ich muss zugeben, ich habe sie noch nicht ausgiebig genutzt. Also, weil wäre interessant, wie du das aufgesetzt hast. Also, ich habe jetzt zum Beispiel ein MacBook. Ich müsste mir was Größeres mit mehr Arbeitsspeicher kaufen. Ich habe zwar so eine kleine Datenkrücke, nenne ich sie immer, aber die hat weniger Arbeitsspeicher als mein MacBook, weil die einfach nur besseres Nass ist.

Ich habe halt auch ein altes MacBook, das so M1-Chip und da probiere ich dann halt Sachen drauf aus, ne?

Mhm.

Der hebt dann, also, ne, das fungiert auch gleichzeitig als Heizung.

Also ich hatte es einmal ausprobiert und ich war überrascht, dass mein MacBook einen Lüfter hat. Ich hatte den vorher noch nicht gehört. Griffheizung für Motorradfahrer, für Entwickler, ja.

Ja, iMacs haben auch Lüfter, habe ich dabei rausgefunden. Ähm. Bei Amex ist es eigentlich ganz praktisch. Dann hast du so einen warmen Luftfilm auf den Händen. Das ist eigentlich ganz angenehm. Also, im Winter ist das... Ja, ja. Tatsächlich finde ich, die Modelle werden ja auch kleiner und leistungsstärker.

Mm.

Und du merkst, oder ich merke in vielen Aufgaben keinen signifikanten Unterschied. Also die Code-Qualität kann bei Cloud genauso daneben liegen wie bei DevStraw. Und je nachdem, was ich mache, merkst du halt den Unterschied nicht. Wenn du gerade so ganz neue Pakete nimmst und Sprachversion und Paketversion, da ist kein Unterschied in der Qualität. Die ist gleich schlecht übrigens bei allen. Ja.

Ja, oder du brauchst die gleichen Voraussetzungen, glaube ich, dafür. Nicht viel, aber du brauchst Tooling drumherum, um gewisse Sachen festzulegen, so ein bisschen die Leitplanken zu definieren und dann viel auf die Finger kloppen, damit PHP-Stand doch ausgeführt wird und nicht ignoriert wird. Bei mir war sie immer sehr kreativ und meinte so, ich kann das nicht lösen, der Test ist falsch, ich muss den Test anpassen. Ich habe immer gedacht, nein, der ist genau richtig. Lass ihn so. Hm.

Ja, also, es gibt ja auch die Möglichkeiten, Hoax-Plugins und so weiter einzubinden und da die Systeme in die richtige Richtung zu zwingen. Alles tausend Möglichkeiten. So ist es ja nun nicht, dass man das jetzt nicht machen könnte. Aber das Kernergebnis, ja, ich sag mal, das, was beim ersten Durchlauf rausfällt, ähm, Da wäre es ja schön, wenn schon möglichst hohe Qualität da ist. Dass sich das an so Kleinigkeiten erinnert wie in, naja, schau mal, in der Paketversion, da gibt es diese Funktion einfach gar nicht mehr. Weil, klar, wenn er dann sagt, ah, ich linde jetzt das PHP, da ist kein Fehler drin und so weiter und so fort, dann landet er irgendwann bei PHPStan und PHPStan sagt, das ist aber Unfug.

Hmm.

Ja, dann hat man das natürlich verhindert und abgefangen. Aber wäre ja schlau, wenn sich die KI einfach so sagt, okay, ich habe jetzt diese Dependency gelesen, ich habe sie verstanden und jetzt setze ich sie auch vollständig so ein und nicht sage, ah, in meinen Trainingsdaten, da gab es aber das. Ja, genau.

die sind halt nicht aktuell. Und das merkt man. Also wenn man an zu neuen Versionen dran ist, sind Sachen einfach nicht da. Die Trainingsdaten sind nicht aktuell. Das ist nicht hilfreich. Aber grundlegend ist es ja auch so, man sollte KI ja eigentlich nicht dafür nutzen, Sachen zu generieren, weil sie nicht deterministisch ist, sondern maximal dazu nutzen, sich Tools und Programme zu bauen, die deterministisch sind. Also bei uns beim Programmieren ist es nochmal etwas besonders. Aber so mein Lieblingsbeispiel ist immer, du kannst der KI sagen, bitte rechne mir mal diese Excel-Tabelle aus. Oder kannst dir sagen, bauen wir ein Python-Script, was alle Excel-Tabellen aus diesem Ordner nimmt und daraus Summen bildet.

Ja, definitiv.

Und der gleiche Gedanke ist ja beim Programmieren auch so ein bisschen. Dieses, wenn ich sage, mach das mal oder grade das mal ab, dann funktioniert das nicht so. Wenn du aber sagst, ich habe Rektor im Projekt und ich möchte diese Sachen machen, gibt es da Regeln für? Dann spuckt die dir ganz schnell Sachen aus oder hilft dir zum Beispiel auch Custom-Regeln zu bauen, um dann Rektor über das Projekt laufen zu lassen. Also... Hm...

Also das ist immer die Frage, welchen Weg geht man und wie sagt man es? Also es ist Vibe Coding, oder es ist Agentic Engineering. Und was ich ganz cool finde bei Mistral, ich habe es ehrlicherweise noch nicht ausprobiert, komplett ist, aber kannst du auch einfach für deine Cloud Feintuning der Modelle machen.

Das hört sich wieder klug an. Hm. Hm.

Wenn du halt weißt, ich nutze jetzt die PHP 8 und ich sage jetzt mal Typo 3 14, also 14.2, dann kannst du das Feintuning auf das Modell machen damit. Und dann kennt das Modell das und dann sind deine Ergebnisse direkt anders.

Das ist ein Thema, ich glaube, da müssen wir mal wieder eine eigene Folge drüber machen.

Naja, bisher habe ich Feintuning auch nur lokal gemacht.

Live-Coding, oh mein Gott.

Also, aber ja, eine eigene Folge ist eine gute Idee. Da können wir dann auch zwei, drei Tage drüber reden. Wir machen das dann als Livestream bei YouTube direkt oder so.

Aber das muss FSK 18 sein. Also die Schimpfwörter, die da fliegen. Mhm.

Aber das ist tatsächlich ein sehr großes Thema. Wie geht man damit gut um? Was kann man machen? Vielleicht machen wir dafür wirklich mal ein paar eigene Sessions. Das entwickelt sich ja auch ständig weiter. Was ich heute sage, ist morgen ja schon wieder veraltet. Ja.

Ja, aber auch die Idee, die wir vorhin hatten mit Agent im Docker-Container und Zugriff reduzieren, das will ich mir nachher mal angucken oder würde ich gerne mal weiter ausprobieren. Vielleicht hat man da etwas, worüber man auch noch erzählen kann. Und dann passt das ja sehr gut zusammen, weil wenn du das im Docker-Container hast, kannst du den auch deployen zum Beispiel oder auch feintunen auf deine besonderen Anforderungen.

Ja, wobei Feintuning im Docker-Container ist, glaube ich, keine gute Idee.

Also mache ich es, ja.

Was auch keine gute Idee ist, kann ich dir schon verraten, dem Container keinen Zugriff aufs Internet zu geben. Weil dann kann er auch so Dinge wie Context 7 nicht abrufen. Das macht dann Ergebnisse noch schlechter. Ja, also das ist ja gerade die Krux mit den Tools. Du musst denen halt irgendwie dafür, dass sie gut funktionieren, musst du ihnen halt viele Rechte geben, wie bei so einem echten Entwickler. Wenn du einen echten Entwickler ohne Internet irgendwo einsperrst, dann werden die wenigsten in kurzer Zeit richtig gute Ergebnisse produzieren. Ja, wir schreiben halt alle nicht wie früher den Code auf Papier oder so und überlegen uns vorher, welche Fehler passieren, sondern wir sind ja sehr, wir machen mal und schauen mal getrieben und wir schauen mal nach. Das ist ja nicht mehr wie bei der letzten Mondlandung.

Ja, du kannst auch nicht alles wissen. und.

So, und wir machen keine Raketenwissenschaft. Sagt auch Outlook, das zum Mond fliegt.

Aber manchmal machen wir daraus eine.

Oder das MPM-Paket, das auch das Dashboard für SpaceX ist. Aber es läuft sogar in Chrome, wenn ich mich richtig erinnere. Ja.

Jungs, warum musstet ihr zwei Gigabyte Note-Modules deployen? Wir brauchten nur ein Dashboard. Hm.

Aber es ist ja tatsächlich jetzt... ist es ja fast schon wirklich egal geworden, weil einfach die Speichermengen so verfügbar sind heute und auch die Datenübertragungsmengen. Also ich meine, wir können gerade von der aktuellen Mondmission HD YouTube Livestreaming sehen. Ja, weil einfach mit einem fucking Laserstrahl die Daten übertragen werden. Mein Sohn hat dazu gestern Abend so schön gesagt, Glasfaser im Weltraum. Ich

Das ist echt geil beschrieben. Mhm.

Ja. So, ich fand, das war die treffendste Beschreibung für das, was da eigentlich gerade gemacht wird, so ein bisschen. Und überleg mal, wir bekommen es nicht mal hin, Glasfaser im Boden hier auf der Erde zu verwenden in Deutschland, flächendeckend, aber wir schicken 4K-Videos durchs Weltall als Livestream.

Also ich muss da jetzt die Telekom bashen. Stefanie, die hätten Probleme. Techniker kommt zwischen 8 und 18 Uhr, um das Kabel anzuschließen.

Ja.

Peace. Wir mögen auch die Telekom. Also wenn wir gesponsert werden.

Ja, ja. Unfassbar. Gut. Ich glaube, dann... war es diese Woche eine wunderbare Secrets Not Included Folge mit Glasfasern-Weltalp-Policies und KI-Modellen, die vielleicht im Container laufen.

Sehr kreativ waren wir ja. Bis dann, ciao.

Ja, hervorragend. Dann sehen wir uns nächste Woche wieder mit einer noch viel besseren, neuen Folge Secrets Not Included. Wenn ihr die nicht verpassen wollt, folgt uns, teilt es, gebt uns einen Daumen hoch, 5 Sterne oder whatever. Und bis dahin, macht's gut. Ciao.