*36C3 Intro Musik*
Herald: Jetzt mit dem Talk 'Das nützlich- unbedenklich Spektrum' Ich muss ihn, wie
gesagt, nicht vorstellen: Fefe.
*Applaus*
*Mikrofonklopfen*
Fefe: Ja guten Morgen. Freut mich, dass das alles hier so voll ist. Ein Glück,
dass das hier nicht Halle 1 ist. Das wäre ja schlimm, so viele Leute. Ja, dieser
Vortrag, ich muss gleich ein bisschen Erwartungsmanagement machen. Ich habe
nämlich eigentlich letztes Jahr einen anderen Vortrag eingereicht über TCB-
Minimierung und das wäre so ein bisschen technisch gewesen. Was man denn machen
kann als Programmierer. Der ist abgelehnt worden. Ich weiß nicht, warum. War voll.
Den habe ich dieses Jahr wieder eingereicht, aber es sollte nicht so
aussehen, als wenn ich die ärgern will, also habe ich noch einen Talk eingereicht.
Den haben die natürlich genommen.So, das heißt, den musste ich jetzt schnell
vorbereiten. *Publikum lacht*
Ja, das Problem ist, das ist eher so ein Gedankengang als eine strukturierte
Darstellung. Ich hoffe, es wird trotzdem hilfreich. Aber es ist nicht so
strukturiert wie meine sonstigen Vorträge. Ich fange einfach mal an. Also es gibt
mehrere Herleitungen, die im Grunde zum selben Ergebnis führen und ich lasse euch
einfach mal teilhaben.Es fing relativ früh in meiner Karriere an, da habe ich mich
entschieden: ich werde nie Software schreiben, von der vielleicht Leben
abhängen könnten, so medizinische Geräte, Atomkraftwerke, war so meine Vorstellung,
Militär natürlich sowieso nicht. Und dann habe ich aber jemanden getroffen, der Code
für Atomkraftwerke schreibt. Und das war so ein Typ: "Ey das ist doch ganz
einfach." Das heißt, wenn die Leute, die ihre Grenzen einschätzen können, das nicht
machen, dann machen es halt die anderen. *Publikum lacht*
Das soll jetzt nicht verallgemeinernd sein. Ich habe tatsächlich noch einen anderen
getroffen, der war nicht so, aber ich meine, diese Art von Personen gibt es
halt. Die Problematik an der Stelle ist, glaube ich, dass man Programmieren
explorativ lernt: das ist häufig nicht so einen Kurs, den man durchgeht, sondern man
läuft halt rum und sucht Grenzen. Das heißt aber auch, dass man per Definition
die Grenzen noch nicht kennt, denn die will man ja gerade finden. Das heißt aber
auch, dass alle Leute im Grunde immer gerade an ihrer Grenze arbeiten. Wenn
Leute Software schreiben, dann gehen sie so weit, wie sie glauben, dass sie gerade
noch können. Und das heißt aber im Umkehrschluss, dass die Technologie, die
da draußen ausgerollt wird, das sind hauptsächlich eben nicht abgehangene
wohlverstandene Sachen, sondern das sind genau die Technologien, die der Typ gerade
noch verstanden hat. Das ist so ein bisschen ein Problem, und das wird nochmal
verstärkt dadurch, dass wir eben heute so eine Modularisierungs- und
Abhängigkeitswelle haben, dass Leute einfach noch Module von anderswo mit
reinziehen und sich einfach im Grunde ohne Grundlage in der Realität vorstellen, dass
derjenige schon wissen wird, was er tut. Und so ist es eben häufig nicht, sondern
das sind genau so Leute wie du und ich, die eben auch explorativ gearbeitet haben.
Das kann man sich auch ganz gut selbst überlegen, wenn man so ein kurzes
Gedankenexperiment macht. Das konnte man auch schon live beobachten. Also nehmen
wir mal an, jemand findet einen Weg, um besser mit Komplexität umzugehen. Zum
Beispiel Modularisierung oder objektorientierte Programmierung, als das
gerade frisch war. Und dann würde man ja hoffen, dass wir die Software, die wir
davor geschrieben haben, jetzt besser machen, weil wir das besser im Griff
haben. Aber das passiert halt nicht, sondern was passiert ist, dass wir dann
eben größere Software schreiben und wieder am Limit arbeiten. Ich glaube, dass das
kein Problem der Softwareentwicklung oder des Programmierens ist, sondern generell
ein Problem mit Menschen. So hat uns die Evolution gemacht, und da müssen wir
lernen mit umzugehen. Und ich will das mal illustrieren: Ich habe so eine Theorie,
die nenne ich die Gradienten-Theorie. Die These ist, dass Menschen ihre Umgebung wie
ein Optimierungsverfahren betrachten in der Mathematik. Das heißt, man hat
sozusagen ein Gelände und sucht den höchsten oder tiefsten Punkt - das ist so
ein Optimierungsproblem. Und dabei geht man eben nicht gezielt vor, wenn man das
Gelände nicht kennt, sondern man muss Annahmen treffen, und das kann man an sich
selbst beobachten. Wenn es zu kalt ist, dann geht man ja zur Heizung und stellt
nicht so ein, wie man es haben will, sondern man stellt heiß, und dann wartet
man, bis es zu warm wird, und dann geht man wieder hin und stellt wieder runter.
Das heißt, wir haben so ein Annäherungsverfahren, wie wir mit der Welt
umgehen. Und das ist nicht nur bei Heizungen. Das ist auch beim Autofahren,
wenn wir so eine Landkarte haben, dann gucken wir uns an, was ist denn das Limit?
Wo müssen wir abbiegen? Und den Weg dahin ignorieren wir, obwohl der vielleicht ganz
schön ist. Viele Sachen, die wir machen, auch die Geschwindigkeitsauswahl, ist so
ein Gradienten-Ding Wir beschleunigen, bis wir uns unwohl fühlen. Dann gehen wir
wieder ein bisschen zurück. Oder wenn man im Wörterbuch oder Telefonbuch
nachschlägt, dann macht man eine Annahme, wo das ungefähr sein wird. Und wenn das zu
weit ist, geht man wieder zurück. Also der elementare Teil ist jedenfalls: wir haben
die Annahme, dass das Gelände ungefähr so aussieht. Wir haben hier eine glatte
Übergänge, und dann funktioniert das Verfahren gut. Das heißt Gradient Descent
übrigens, dass man versucht, der Schwerkraft hinterherzulaufen und den
tiefsten Punkt zu suchen. Aber es funktioniert in zwei Fällen eben nicht
gut: Der eine ist, wenn es einen Abhang gibt, über den ich rüberlaufe und dann
kann ich nichts zurück korrigieren. Und das läuft auch nicht gut, wenn man nicht
merkt, wenn man zu weit gegangen ist. Also ist so ähnlich wie der Abhang, und das
zweite Problem ist, wenn man nicht zurückrollen kann, aus anderen Gründen.
Die gibts in der Softwareentwicklung eben häufiger, und es stellt sich heraus, sind
genau die Art von Problemen, die Menschen haben. Zum Beispiel, wenn wir so was haben
wie zwei Wochen Probeabo, dann vergessen die Leute halt, da wieder auszutreten,
oder Drogenabhängigkeit ist ein Klassiker, Spielesucht. Und in der
Softwareentwicklung oder überhaupt im Projektmanagement ist es häufig: Jetzt
haben wir schon so viel investiert, jetzt können wir nichts zurück. Security ist
kein Gradient, es sieht vielleicht aus wie ein Gradient, aber es ist keiner. Das ist
gerade, glaube ich, das Grundproblem von der IT-Security. Man merkt nicht, wenn man
zu weit gegangen ist. Das merkt man erst, wenn man gehackt wird. Und dann kann man
nicht mehr zurückrollen. Dann sind die Daten schon weg. Komplexität ist ähnlich
wie Security auch kein Gradient, aber es fühlt sich an wie einer. Und das ist,
glaube ich, der Grund, warum wir damit so schlecht umgehen können. Das fühlt sich
an, als würden wir alles unter Kontrolle haben. Und zu dem Zeitpunkt, wo wir
merken, dass es nicht mehr so ist, können wir nicht mehr zurück. Übrigens ist auch
Daten rausgeben so an Facebook oder so ist genauso ein Pseudo-Gradient, nenne ich das
mal. Zu dem Zeitpunkt, wo man merkt, dass man zu viel rausgegeben hat, ist es zu spät.
So die Schlussfolgerung ist eigentlich: Komplexität ist böse. Wir bemerken sie zu
spät und wir fangen sie uns auch zu leichtfertig ein. Und da muss man halt irgendwie
gegensteuern. Die Kosten dafür werden im Moment an unsere Kunden, wenn wir das
beruflich machen, externalisiert, an unsere Benutzer und an unser zukünftiges
Selbst. Daher findet man relativ selten glückliche ältere Softwareentwickler.
*Publikum lacht* So, das war der erste Gedankengang, der
mich in die Richtung geführt hat. Der zweite Gedankengang: Ich will jetzt mal
das GNU Manifesto herausgreifen. Stellvertretend. Das ist kein GNU-Bashing
hier, aber am GNU Manifesto kann man das ganz gut zeigen. Das war die ursprüngliche
Ankündigung des GNU-Projekts von Richard Stallman. Da hat er geschrieben: "Wir
machen Unix-Programme, und wir werden aber nicht genau dasselbe sein wie Unix. We
will make all improvements that are convenient." Das ist ein ganz furchtbarer
Satz. Was heißt denn 'convenient', für wen denn? Aber das ist genau die
Herangehensweise, die viele Leute haben, die Software schreiben: "Oh, das können
wir noch schnell dazutun." Was fehlt, ist so ein Korrektiv, dass man vorher drüber
nachdenkt: "Was hänge ich mir eigentlich gerade für eine Legacy ans Bein?" Ich
glaube dieser Convenience-Gedanke beim Erweitern von Software ist unsere Erbsünde
- um hier mal ein bisschen katholisch zu werden - in der Softwareentwicklung. Die
haben alle schon einmal begangen und das kriegt man eben nicht nachkorrigiert.
Daher ist der einzige Weg, das loszuwerden, wenn man die ganze
Software oder das ganze Modul wegschmeißt und neu macht. Aber Software stirbt halt
nicht. Ich habe im Umgang mit Software erst verstanden, dass es gut ist, dass
Menschen sterben, weil das ist ein Korrektiv, was gebraucht wird. Wenn System
besser werden soll, dann muss der alte Scheiß auch irgendwann sterben können. Und
das passiert bei Software halt nicht. Es ist ein Feature, dass Dinge nicht ewig
halten. Man kann das allgemein beobachten, wenn jemand seine Software erweitern will
und er hat die Wahl zwischen "Wir machen jetzt hier mal was, um das konkrete
Problem zu lösen" oder "Wir machen hier was, um ein allgemeineres Problem zu
lösen." Dann werden die Leute immer das allgemeinere Problem zu lösen versuchen.
Viel Feind, viel Ehr. Und das kann man fast flächendeckend beobachten. Es gibt
sehr wenige Ausnahmen davon. Und ich hatte meinen Aha-Moment, als ich eines Tages mal
gdb aufgerufen habe auf ein Projekt, also ich habe jetzt hier /tmp genommen, aber
das Projekt war irgendein Checkout. Ich habe in meinem eigenen Webserver
einen .gdbinit. Das ist eine Konfig-Datei für den GNU-Debuger, wo man zum Beispiel
sagen kann: "Ruf das Programm, wenn ich es debuggen will, mit diesen
Kommandozeilenargumenten auf!" Und da schreibe ich dann rein: "Nimm nicht Port
80, weil das klappt nicht, sondern nimm Port irgendwie 8005 oder so, was-weiß-ich,
halt localhost zum debuggen." Und gdb hat eines Tages angefangen zu sagen: "Nee, die
.gdbinit-Datei, die nehme ich aber nicht, denn die liegt hier in einem Verzeichnis,
was du nicht freigeschaltet hast." Und das war genau so ein Versuch, diesen Fehler
nach Werk, nach der Tat zu korrigieren. gdb hat festgestellt: "Unsere Konfig-Datei
ist so mächtig geworden, dass es ein Sicherheitsproblem darstellt", und hat dann
halt die ganze Konfig-Sache zugenagelt für rückblickend. Und das hat halt mehr
kaputtgemacht, als nötig gewesen wäre - vielleicht, weiß ich nicht - aber es war
für mich sehr ärgerlich. Man kann hier so einen Autopfad eintragen, aber da ist mir
das halt zum ersten Mal so richtig aufgefallen. Das war jetzt vor ein paar
Jahren. Ich weiß gar nicht, wann das genau war. Es gab so einen ähnlichen Fall
nochmal: mit vim, dem Editor, den ich immer benutze. Da kann man nämlich so
Sachen machen wie in einem Kommentar in der zu editierenden Datei in den ersten
drei Zeilen oder in den letzten drei Zeilen kann man so ein paar Konfig-
Settings ändern. Das ist gedacht, um zu sagen: "Ich benutz' hier in Tabstop von 4 oder
so." Aber der Parser dafür hat ein Sicherheitsproblem gehabt, und damit war
es dann möglich, sozusagen eine Datei zu erzeugen, die ein Programm ausgeführt hat,
wenn sie in vim geöffnet wurde, was natürlich nicht gewollt war. Aber es ist
dasselbe Problem in grün. Und ich glaube, das Problem kann man ein bisschen
verallgemeinern, nachdem ich gerade gegen Verallgemeinern gewettert habe, aber in
der Betrachtung ist Verallgemeinern ja gut, in der Software eher schlecht. Ich
will das mal ein Beispiel illustrieren. Nehmen wir an, wir haben eine CSV-Datei
mit irgendwie Trouble-Tickets. Feld 4 ist das, an dem wir jetzt Interesse haben.
Nehmen wir an, die sieht so aus. CSV halt. So, und jetzt möchte ich da gern die Summe
der vierten Felder haben. Dann mache ich als erstes mal cut, wir sind halt unter
Unix. Der filtert es hier raus, die erste Zeile muss noch weg, also mach ich
hier noch einen tail. Dann ist die erste Zeile weg, jetzt muss ich noch eine
Summe bilden. Da gibt es auch ein Programm für: paste. Wie man das halt macht unter
Unix. Und dann muss ich das ausrechnen. So! Aber was ist denn, wenn da jetzt nicht
1 stand, sondern fred? Dann können wir feststellen: cut hat damit kein Problem,
tail hat damit kein Problem, paste hat damit kein Problem, aber bc fällt auf die
Fresse. So, das heißt, schlimmer noch: bc ist programmierbar. Da könnte jetzt zum
Beispiel die Ackermann-Funktion stehen und dann steht der Rechner für eine Stunde,
während er versucht, irgendeine Rekursion aufzulösen. Und ich glaube, das ist
sinnvoll, hier ein Konzept einzuführen und zu sagen: cut, tail und paste sind
harmlos, bc nicht. Das war so einer der Gedanken, wo ich dachte: "Okay, da kann
man eigentlich mal ein Vortrag drüber machen." Allerdings ist es nicht
hinreichend. Es gibt verschiedene Arten von Harmlosigkeit. Aber ich glaube, die
Unterscheidung ist schon mal hilfreich. Ja, sagen wir mal, versuchen wir es einmal
zu formulieren: Software ist harmlos, wenn unerwartete Eingaben kein unerwartetes
Verhalten oder unerwartete Arten von Ausgabe erzeugen. Zum Beispiel, so eine
SHA-Checksumme ist immer harmlos: Egal, was ich dafür Daten rein tue, die
Ausgabe hat ein bekanntes Format. Oder word count (wc) ist auch so ein Ding.
Jetzt könnte man sagen: "Okay, nimm doch noch awk!" Und in awk habe ich zum
Beispiel kein Problem, wenn da jetzt fred steht statt 4 und der Interpreter
interpretiert ja auch nicht Funktionen. Das sieht besser aus, aber es ist auch
harmlos, und es stellt sich heraus: awk ist eine andere Art von nicht harmlos,
denn man kann im Code im Dateisystem rumschreiben. Da muss ich jetzt nicht auf
die Eingabe achten. Aber ich muss auf die andere Eingabe achten, nämlich den Code,
den ich auf der Kommandozeile übergebe. Und da kann man eigentlich auch sagen,
dass man die Unterscheidung haben möchte. Das ist in der Industrie übrigens ein
großes Problem: Die Spieleindustrie ist dazu übergegangen, in großem Stil
irgendwelche Interpreter in ihre Spiele einzubauen, um die Business-Logik, also
nicht die AI, sondern so kleine Skripte in einer Skriptsprache machen zu können und
einer der beliebtesten Skript-Interpreter dafür ist Lua. Und Lua wird vor allem
deswegen genommen, weil der halt nix kann, was man nicht freischaltet. Also der kann
nicht Datei öffnen, kann keine Sockets aufmachen. Das kann man alles nachreichen,
und dann hat man natürlich wieder ein Problem. Aber das ist ein reales Problem.
Viele Open-Source-Leute denken da nicht drüber nach, weil sie sich denken: "Ach,
ich liefer das aus und der Rest ist ja nicht mehr mein Problem." Aber ich finde,
da müssen wir mal generell drüber nachdenken, und zwar am besten vor dem
Ausliefern, am besten schon beim Programmieren. Also das ist eine andere
Art von Harmlosigkeit. Vorher war die Harmlosigkeit: "Kann eine böse Eingabe böse
Ergebnisse erzielen?" Und jetzt ist: "Kann das Programm selbst böse Dinge machen?"
Und das ist eigentlich eine sehr moderne Überlegung, weil wir heutzutage viel mit
Sandboxing arbeiten. Da geht es genau darum, zu verhindern, dass ein Programm
versehentlich oder absichtlich böse Dinge tut. Und da gibt's wieder auch verschiedene
Sachen, die ein Programm anstellen kann. bc konnte Rechenzeit verbraten. awk kann
im Dateisystem lesen und schreiben, und das geht natürlich weiter. Kommen wir
zurück zum GNU Manifesto: GNU awk ist eine spezielle Version von awk und die kann
Sockets aufmachen, völlig ohne Not. Das heißt, wenn wir einfach awk benutzen und
denken, ach awk kann im Dateisystem schreiben, aber das hab ich read-only
gemountet, da passiert schon nichts. Dann ist aber GNU awk im Einsatz, ist es halt
doch wieder nicht harmlos. Bash kann übrigens auch Sockets aufmachen! Ich weiß
nicht, wie viele Leute das wussten? Gut, die Sache geht natürlich noch weiter: Nach
awk kam Perl. Das ist noch viel schlimmer und Perl kann eval(), das ist so das
schlimmste Übel, was man haben kann in einer Programmiersprache aus meiner Sicht. Ein
bisschen näher am Endkunden kann man das auch an Browsern betrachten. Also gucken
wir uns zum Beispiel mal Netscape an: Netscape hat auch mehrfach die Wahl gehabt
zwischen nützlich und harmlos und hat immer nützlich gewählt. Es ging dann los
mit den Plugins. Weiß nicht, wer sich hier noch an das Flash-Plugin erinnert, oder
vorher hatten wir alle den RealPlayer und das [Adobe] Acrobat-Plugin gab es auch
mal - und das war alles scheiße, weil diese Plugins Native Code waren: die
konnten alles tun, was das Betriebssystem ihnen erlaubt. Das heißt, das war zwar
sehr nützlich, aber es war eben auch sehr gefährlich. Und das war eine bewusste
Entscheidung von den Browsern, das zuzulassen. Das eigentliche Ziel von
diesem Vortrag ist, den Programmierern unter euch so ein bisschen das Bewusstsein
dafür zu geben, dass man nicht einfach eine Plugin-Schnittstelle einbaut, die
alles kann. Die nächste Iteration war: Wir machen einfach alles in JavaScript. Das
war, sah erst mal besser aus, aber dieser JavaScript lief dann auch mit genügend
Rechten, um im System Mist anzustellen und zumindest im Browser Mist anzustellen. Da
stellt sich heraus: Die Leute haben ihre wichtigen Daten heutzutage im Browser,
weil sie Onlinebanking machen. Und das reicht, um richtig doll Schaden
anzustellen. Da musste auch nachkorrigiert werden. Chrome limitiert jetzt noch weiter
aus Sicherheitsgründen, um den Adblocker kaputtmachen zu können. Das ist eigentlich
immer dieselbe Falle, in die wir hier reinlaufen. Ich weiß nicht, wer hier
Windows benutzt? Unter Windows gibt es ein Tool, das von Mark Russinovich - der hat
sich inzwischen kaufen lassen von Microsoft, ist jetzt also ein offizielles
Microsoft-Tool. Und die einzige Funktion von dem Tool ist, die verschiedenen
Plugins zu listen, die im System eingetragen sind. Und ich habe hier mal
ein relativ sauberes System genommen. Es geht jetzt nicht um das hier unten oder
die Größe von dem Scrollbalken, sondern einfach, wie viele Tabs es oben gibt: Das
sind alles Möglichkeiten, wie sich Plugins im System einnisten können, und das hat
einfach niemand mehr im Blick, weil einfach immer in die falsche Richtung
entschieden wurde. Also, das ist, glaube ich, ein Kernproblem. Es gab noch eine
dritte Herleitung: Mein Security-Alltag besteht darin, dass sich Firmen gehe und
zeigen mir ihren Quellcode und dann suche ich nach Bugs. Und dann sage ich denen,
welche Bugs ich gefunden habe. Und da gibts dann halt gelegentlich so Fälle, wo
man mitkriegt: Da gibt's ganz viele Bugs, ja gar nicht mal nur die, die ich finde,
sondern die haben schon eine eigene Datenbank, einen Bugtracker, und da sind
schon siebenstellig Bugs drin. Ja, sowas kommt vor. Und weil das so ein Problem
ist, dass wir so viele Bugs haben, gibt's jetzt Gegenstrategien von den Entwicklern,
die dann anfangen zu sagen: "Okay, wenn der Bug nicht wichtig ist, dann kann ich
ihn ja später fixen." Und das heißt in der Realität: nie. Der liegt dann halt rum.
Ich versuche seit einer Weile, den Begriff Bug-Welle dafür zu etablieren, die man
vor sich herschiebt als großer Dampfer. Aber Bugtracker sind in der Realität da
draußen häufig riesige Daten-Endlager: Ich habe zum Beispiel neulich einen Bug
bei Firefox gemeldet und habe die ID 1.590.000 gekriegt. Das ist ja schon
ein schlechtes Zeichen, eigentlich. Aber es ist ein gutes Zeichen, weil der
Bugtracker offen ist. Bei Microsoft kann man das gar nicht sehen, wie viel Bugs die
haben. Das ist jetzt hier nur als Illustration gemeint. Mozilla ist nicht
besonders scheiße. Mozilla hat nur einen offenen Tracker, an dem ich das schön
etablieren kann. Was ich jetzt noch zeigen wollte - ich hab noch mal geguckt: "Was ist
denn der erste Bug, den ich da gefiled habe?" Der hatte noch eine sechsstellige
ID. Das war 2003. Wenn man sich den Verlauf anguckt, der Bugnummern, dann
stellt man fest: Das wächst exponentiell. Und es ist nicht so, dass die Bugs dann
irgendwie irgendwann weggehen von irgendwann. Ich habe zwei große Ereignisse
beobachtet, bei denen Bugs geschlossen werden: Das ist, wenn es ein neues Release
gibt, und da schmeißt man die alte JavaScript-Engine raus und macht eine neue
rein. Dann schließt man alle Bugs von der alten Engine. Das sieht dann so aus, als
wenn man was geschafft hat. Und der andere Weg ist dieser hier: Ich weiß nicht,
ob man das hinten lesen kann? Mozilla hat einfach einen Bug von mir geschlossen. Da
steht drin: "This bug has been automatically resolved after a period of
inactivity". Die war jetzt nicht von mir, die Inactivity. Ich hab den Bug gefiled,
und bei Mozilla hat sich keiner drum gekümmert. Und dann haben die den halt
automatisch geschlossen, weil die Statistik so schlecht aussah. Das ist ein
Riesenproblem, nicht nur bei Mozilla. Wie gesagt, das ist hier nur der
Blitzableiter, den ich zeigen kann, weil es alles öffentlich ist bei denen. Aber
das führt zu so einer Kaskade aus Verhalten und Gegenverhalten. Zum Beispiel
sieht man dann: unwichtige Bugs werden halt gar nicht gefixt. Und dann schreiben
die Leute halt "wichtig" an ihre Bugs, wenn sie wollen, dass die gefixt werden.
Und da haben die Leute gesagt: "Okay, die wichtigen Bugs bleiben dann
auch liegen, weil da gibt's zu viele von." Und dann schreiben die Leute
"Security" an ihre Bugs ran, und dann haben wir jetzt eine Welle von Security-
Bugs, und da wird dann verhandelt: "Ist das denn wirklich ein Problem?" Und da kommen
dann so Ausreden, wie: "Ist ja nur ein Crash." Und der Punkt daran ist, dass es
hier eine unheilige Allianz gibt mit einem anderen Trend, nämlich, dass Firmen
einfach sehen: sie haben so viele Bugs offen, dass es gar nicht das Ziel ist, sie
alle loszuwerden. Es gibt einfach zu viele, das ist unrealistisch. Stattdessen
führt man Metriken ein, wie dass man Fuzzing macht. Fuzzing ist
eigentlich keine doofe Idee, aber es ist eben nicht: "alle Bugs finden", sondern es
ist nur der erste Schritt auf einer langen Straße. Aber es ist halt eine schöne
Metrik, die da rausfällt. Wir haben so und so viel Fuzz-Testcases gemacht, und jetzt...
Sind wir jetzt besser oder schlechter als vorher? Ist alles schwer zu sagen.
Dann gibt es Bug Bounties, was ich persönlich für Bullshit halte. Das macht
man, damit die PR-Abteilungen zeigen kann: "Guck mal, so viel wert sind Bugs bei uns,
weil wir so wenig Bugs haben." Das ist die Idee. Und der Rest der Industrie hat
einfach Mitigations gemacht. Da haben Sie dann gesagt: "Okay, wir schließen die Bugs
nicht mehr, wir machen das Exploiten schwieriger." Und das funktioniert. Ich
bin da immer dagegen gewesen. Ich musste also jetzt meinen Hut fressen, sozusagen.
Das funktioniert. Aber es hat halt Nebeneffekte. Ich weiß nicht, ob ich Zeit
habe für Anekdoten. Ich bin nämlich zeitlich sehr knapp dran. Aber ich hab mal
den Typ getroffen, der die Internet- Explorer-Bugs verwaltet, die reinkommen,
und ich habe den getroffen, weil ich 50 Bugs gefiled habe. Und er hat gesagt "35
kenne ich schon". *Publikum lacht*
Und da hab ich gesagt: "Wie jetzt?" Der
Typ sah aus wie Gollum in so einer Cave. Der war irgendwie 30 und sah aus wie Ende 60.
*Gelächter* Und der meinte: "Es kommen so viele Bugs hier rein, wir kommen gar nicht dazu,
irgendwelche zu schließen, wir verwalten die nur noch." Das war der Stand
damals. Das ist inzwischen besser geworden. Also Microsoft. Und wie gesagt,
das sind hier Beispiele, das ist in anderen Firmen ähnlich. Man verwaltet die
Bugs, und man schließt sie nicht mehr, und memgc ist eine Sache, da habe ich lange
Jahre gar nicht drüber reden dürfen. Aber inzwischen haben sie das selbst
veröffentlicht. Deswegen darf ich das jetzt doch erzählen. Da haben sie halt
festgestellt Wir haben lauter Memory Corruption Bugs, weil wir immer die Sachen
vom Heap free()n und dann aber noch benutzen. Da haben Sie jetzt einen Hack
gebaut, der die Sachen dann halt nicht free()t, sondern in eine Liste tut. Und
dann läuft ja über den Stack und guckt nach Pointern, die in die Liste zeigen und
gibt die dann nicht frei. Das ist ein furchtbarer Hack. Wär' mir ja zu peinlich
gewesen, das irgendwo zu erwähnen. Aber Microsoft macht jetzt PR damit, wie geil
memgc ist. Und die Chrome-Leute haben sich das angesehen haben und gesagt:
"Boah, das ist ja geil." *Publikum lacht*
Das ist der Stand, wie die Industrie
funktioniert. Das Problem ist jetzt aber, dass Bugs nur noch mit Exploit als
Security-Problem anerkannt werden. Also das ist nicht branchenübergreifend, aber
es ist bei vielen inzwischen so: Wenn man keinen Exploit liefert, wird es nicht
anerkannt. Aber wir haben ja vorhin gesehen, dass überhaupt nur noch
anerkannte Security-Bugs gefixt werden. Das heißt, Bugs liegen einfach herum, weil
der Nachweis nicht erbracht werden konnte. Und wenn das Ausnutzen von einem Bug durch
die Mitigations schwieriger wird, heißt das eben, dass immer mehr tatsächliche
Sicherheitsprobleme rumliegen, weil niemand Bock hat, den Nachweis zu
erbringen, dass es ein Problem war. Das heißt nicht, dass keiner von den Bugs
jemals geschlossen wird. Denn es stellt sich heraus: Die Entwickler haben so etwas
wie einen Anspruch an ihren Code. Keiner möchte der Typ sein, der die Brücke in
Genua gebaut hat. Das heißt, die Leute laufen schon rum und schließen Bugs. Aber
sie möchten halt nicht gezwungen werden dazu. Und sie möchten auch nicht
anerkennen, dass es ein Problem war. Und das hat so eine Kaskade an Problemen in
der Realität. Aber ich schließe daraus: Erst mal reaktiv auf das Problem mit den
Bugs und der Softwarequalität zuzugehen, hilft eigentlich nicht. Ich sage das schon
länger über Viren und Würmer und die Antiviren, die ich immer als Schlangenöl
bezeichne. Ich glaube, dass das bei Bugs auch so ist: Viel zu viel Software wird
einfach entwickelt, und man denkt sich: "Ach naja, dann können wir das mal ausliefern,
und der Kunde testet das dann. Und dann melden die schon die Bugs und die fixen
wir dann halt." Es gibt so inzwischen das geflügelte Wort: Man liefert aus, wenn der
Updater funktioniert. Und da muss man ja irgendwie mit umgehen als Industrie. Ich
versuche hier als Zielgruppe jetzt die Entwickler. Was machen wir denn jetzt? Das
ist jetzt so die Frage. Und da gibt es natürlich verschiedene Ideen: Der FDP-
Ansatz ist meines Erachtens gescheitert. Der Markt hat ja gar nichts geregelt. Die
Leute kaufen immer noch alle irgendwie Windows und macOS. Das funktioniert,
glaube ich, nicht. Dann kann man versuchen, an die Moral zu appellieren.
Freiwillige Selbstkontrolle? Das funktioniert auch nicht aus meiner Sicht.
Dann gibt es den BSI-Ansatz: "Wir tun einfach ein paar Lagen Schlangenöl drüber..." Das
funktioniert leider auch nicht. Und es gibt den Twitter-Ansatz: Ausgrenzung
und mit Dingen drohen. Heugabelmobs. Das hat in meiner Beobachtung eher zu
Abandonware geführt, weil die Leute halt weggerannt sind, und gesagt haben:
"Das ist mir doch egal. Das ist nicht mehr meine Software." Es gibt auch einen
Hybridansatz, den die katholische Kirche seit vielen Jahren erfolgreich fährt.
Vielleicht ist das die Lösung. Dass man sagt: "Nicht der Markt, aber Sankt Peter
regelt das." Und an Moral appellieren funktioniert so ein bisschen. Das müssen
wir vielleicht ausbauen. Und dann dachte ich mir: "Was machen wir jetzt konkret?" Ich
habe als erstes gedacht: "Wir müssen vielleicht gucken, ob wir die explorative
Softwareentwicklung von der zielorientierten Softwareentwicklung
trennen." Dass wir sagen, es ist gut und richtig, dass die Leute explorativ lernen.
Aber das ist dann nicht das Produkt, was du shippst. Da müssen wir irgendwie
hinkommen. Und ich appelliere seit Jahren an die Firmen und sage: "Gebt den Leuten
Zeit, dass sie ein bisschen rumspielen und Sachen lernen können!" Denn sonst lernen
sie das während der Produktentwicklung und dann wird das Produkt halt scheiße. Aber
da kann ich so lange reden, bis ich blau anlaufe. Der Effekt ist bisher nicht
vorzeigbar. Ich finde, man kann das gut auf den Punkt bringen, wenn man sagt:
"Sei innovativ damit, was du tust, und nicht, wie du es tust." Eine Firma soll ja
innovativ sein, soll Dinge probieren, neue Produkte machen, aber dann nicht
irgendeine Experimental-Datenbank-Tech anwenden, die dann irgendwie mit den Daten
verloren geht, weil - war noch nicht fertig. Ich glaube, es gibt da nicht nur
eine Ursache, sondern es gibt mehrere Komponenten und die muss man auch getrennt
betrachten. Die erste ist Unwissenheit. "Ich weiß einfach nicht, dass der Code
scheiße war, den ich da importiert habe." Oder "Ich wusste nicht, wie man es besser
macht, deswegen habe ich es halt nicht gut gemacht." Und dann gibt's, was ich mal
absichtliche Unwissenheit nenne: "Wir haben keine guten Leute gefunden." Das
halte ich für eine Ausrede. Wer möchte und wer gut zahlt, findet auch gute Leute.
Solange das Projekt irgendwie so ein bisschen was an sich hat, was man
vielleicht mal ausprobieren möchte. Das halte ich für eine Ausrede. Ich glaube,
das sagen Leute, die sagen: "Ach, es ging halt nicht anders, wir haben schlechte
Leute. Dann wird das Produkt halt nicht so gut. Es macht ja nix. Also war nicht meine
Schuld." Halte ich für eine Schutzbehauptung. Und dann gibt es
natürlich Inkompetenz. Also so richtig. "Ach, das ging gar nicht anders." - ich habe
neulich so einen Kunden gehabt. Das sieht häufig nicht aus wie Ausreden,
sondern wie Best Practices. Aber ich halte es für Ausreden. Ich habe neulich so einen
Kunden gehabt, die meinen jetzt: "Wir machen jetzt eine Plattform für
Energiehandel", also kritische Infrastruktur, würde man eigentlich sagen.
Die haben gesagt: "Wir machen das in der Cloud, weil selber hosten können wir gar nicht."
- "Ja, warum denn nicht?" - "Das ist so teuer."
*Publikum lacht*
Verstehe ich nicht. Ich glaube, wir haben da so eine Kaskade aus Ausreden, die vor
uns hergeschoben werden. Der Ansatz, den ich jetzt gehen möchte, ist, dass ich
sage, wir versuchen vielleicht so eine Art Legacy-Faktor zu definieren, den man
an die Software dran schreibt. Und da geht es nicht darum: "Wie schlecht ist die
Software?", sondern "Wie negativ beeinträchtigt wird meine Software, wenn
ich das als Dependency reinnehme?". Also wenn ich jetzt irgendeine Library
reinziehe, wieviel negative Auswirkungen hat das? Das Problem ist aber: Wenn wir
das als Metrik machen und die wird irgendeine Art von Erfolg im Markt haben,
dass die Leute dann natürlich bescheißen werden und werden nach der Metrik
optimieren und nicht nach dem tatsächlichen Ziel der Metrik. Daher ist
das so ein bisschen schwierig, aber es gibt ein Vorbild, was so ein bisschen
funktioniert, nämlich das CVSS - das das Common Vulnerability Scoring System. Das
wird angewendet, um die Problematik von Bugs zu messen. Da haben sich also
Leute zusammengetan und versucht, eine Metrik zu definieren. Und die funktioniert
in der Industrie gut, die wird angenommen. Die Leute lieben das. Das funktioniert
grob so, wie eine historische Risikobewertung. Man guckt halt so, wie
wahrscheinlich ist, dass das passiert, dass das jemand ausnutzt. Da gibt's dann
Kriterien wie: Ist das technisch aufwendig? Kommt man da ran, wenn man
lokal einen Account hat oder auch über Netzwerk? Und was macht man denn kaputt,
wenn man das ausnutzt? Kann man dann Daten löschen, oder kann man die verändern? Also
diese Art von Sachen klickt man an, und dann kommt ein Score raus. Das finde ich
eigentlich eine gute Sache. Ich glaube, wir brauchen so ein Risiko-Score - jetzt
nicht für Bugs. Bei Bugs ist es, glaube ich, einfacher zu machen, obwohl es auch
schon viele Detail-Schwierigkeiten hat. Aber eigentlich brauchen wir so eine Art
Risiko-Score, entweder für das Management oder für die Entwickler. Und das sind
getrennte Probleme. Ich glaube, dass es zielführender, sich an die Entwickler zu
halten. Denn ich habe bisher noch fast nie erlebt, dass Management gesagt hat: "Das
muss jetzt besser werden. Und das war nicht nur als PR gemeint." Sondern, aber
Entwickler haben so eine Art Anspruch an ihren Code. Und ich glaube, wenn man denen
hilft zu erkennen, ob sie gerade einen Fehler machen, können wir was stemmen.
Dann habe ich mir gedacht: Welche Dimensionen gibt's denn da? Das ist leider
ein mehrdimensionales Problem. Hier ist eine der Dimensionen, die ich mir überlegt
habe: Sicherheitslöcher. Gut, klar. Wenn der Code Sicherheitslöcher hat, ist das
ein Problem. Aber das ist leider ein offenes Forschungsfeld, wie man die
Sicherheitslöcher finden soll. Und vor allem dafür eine Metrik zu haben. Jetzt
kann man sagen: "Wir haben jetzt 10 Bugs gefunden, also war der Code wahrscheinlich
unsicher." Und da ist was dran. Aber wir wissen ja nicht, ob das alle 10 Bugs in
dem Code waren. Ist der Rest von dem Code vielleicht super, und das waren 10
Ausrutscher? Das ist leider sehr schwer zu messen. Daher eignet sich das, glaub ich,
nicht als Metrik. In der Industrie gibt es Versuche, mit Code-Smells und statischer
Analyse zu arbeiten. Das ist eine Sache, die im Moment sehr viele Firmen
ausprobieren.Der Erfolg ist bisher eher mäßig. Meine Beobachtung ist, dass man so
ein Tool ausrollt, und der wirft dann zehn Milliarden Warnungen. Und dann schaltet
man so lange die Sensibilität von dem Tool runter, bis die Menge verarbeitbar
ist. Und dann verteilt man das an die Entwickler, und die sagen: "Das sind aber
alles False-Positives", und dann ist das Projekt gescheitert. Dann lässt man das
weiterlaufen, damit es nicht so aussieht, als wäre es gescheitert. Aber dass
tatsächlich was passiert, ist selten. Das ist zwar eine wichtige Dimension, aber ich
glaube, die können wir nicht ordentlich in eine Metrik abbilden. Ich wüsste jedenfalls
nicht, wie. Ich versuche das hier auch an Beispielen zu illustrieren, vielleicht ein
bisschen. Es gibt Extrema: es gibt einmal qmail und sendmail. Das sind eigentlich
ganz gute Illustrationsbeispiele: Das sind beides MTAs, also Programme, die auf einem
Server laufen und Mails weiter verschicken oder annehmen.Und qmail ist gebaut worden
mit dem Ziel, eine sichere Software zu haben, da hat sich jemand erst das Design
überlegt und dann die Software so gebaut. Und sendmail ist erst geschrieben worden,
dann kam jemand und meinte "Ja, vielleicht brauchen wir auch ein Design", und das
sieht man bis heute. qmail ist um 1993 veröffentlicht worden, ging bis Version
1.0.3, und danach gab es nie wieder einen Patch. Und ich setze das aber bis heute
ein, weil es da nie wirklich Probleme gab, das ist sozusagen fertige Software. Das
ist so das eine Ende. Auf der anderen Seite heißt es aber auch, dass neuere
Features einfach nicht drin sind. Es ist immer ein zweischneidiges Schwert. Das ist
das Spektrum, auf dem wir uns bewegen: auf der einen Seite so ein alter Legacy-
Codehaufen, den keiner mehr wirklich verwalten will, außer er wird bezahlt
dafür. Und selbst unter den Leuten, die bezahlt wurden, sind die meisten
weggelaufen, übrigens. Das will einfach niemand haben. Die zweite Dimension, über
die man nachdenken kann, ist: "Gibt es denn noch Wartung dafür?". Das kann man bei
Open-Source-Produkten glücklicherweise ganz gut erkennen. Bei kommerzieller
Software ist das ein bisschen schwieriger, weil da gibts dann vielleicht Patches und
neue Versionen. Aber ob die auch tatsächlich was ändern, ist halt nicht so
klar. Oder wie viel sie ändern. Und das ist auch nicht so klar, wie man das jetzt
bewerten soll, denn wenn eine Software keine Updates kriegt, muss es ja nicht
heißen, dass sie scheiße ist. Kann ja auch sein, dass die einfach fertig ist. Das ist
zwar sehr, sehr selten, aber es gibt Beispiele dafür: Zum Beispiel: TeX ist ein
Satzsystem von Donald Knuth. Das hat er geschrieben und ist jetzt fertig. Da gibt
es zwar immer noch Patches, gelegentlich, aber ganz selten. Und die ändern zwei Bits
irgendwo. Das ist im Wesentlichen fertig. Oder libjpeg habe ich hier als Beispiel
genommen, das ist irgendwann geschrieben worden von der Independent JPEG Group um
Tom Lane und das hat eigentlich nie irgendwelche Updates gebraucht. Das war
einfach. Hat auch keine Sicherheitslücken gehabt. Das ist deswegen jetzt nicht
schlecht. Das heißt, dass es nicht so einfach zu sagen: "Es gibt keine Patches
mehr - also ist die Software scheiße." Die Metrik ist also auch sehr schwierig. Wie
machen wir das? Gute Frage. Gut, das hab ich jetzt schon erzählt. Auf der anderen
Seite ist es so: Wenn eine Software sehr häufig geupdatet wird, ist das auch nicht
unbedingt ein gutes Zeichen. Ich habe einen Kunden, der hat eine Software von
einem Drittanbieter, und der releast per GitHub. Und da kommen dann pro Tag fünf
Updates, und da steht aber jedes Mal Release dran. Und gelegentlich brechen die
was, gelegentlich nicht. Da hast du nie irgendeinen Ansatzpunkt, um auch nur zu
beurteilen, ob die Software jetzt gut ist oder nicht. Weil in dem Moment, wo deine
Untersuchung fertig ist, gibts schon wieder 20 neue Versionen. Ja, das ist
eigentlich auch nicht gut. Eine weitere Dimension ist die Dependency-Hölle, die
kennt ja fast jeder, der schon mal Software entwickelt hat. Besonders krass
ausgebildet bei JavaScript, die ein paar Mal sehr öffentlich auf die Fresse
geflogen sind, als zum Beispiel jemand ein Modul zurückgerufen hat, von dem sich dann
herausstellte, dass das irgendwie über transitive Abhängigkeiten in fast allen
Projekten irgendwie drin war. Das müsste man dann transitiv anwenden. Wie gesagt:
Wenn ich eine Software reinlade und die hat 50 andere Dependencies, dann muss ich
die Summe davon nehmen. Die Extrema dabei wären auf der einen Seite so eine Cloud-
Lock-in-Hölle, wo man die Abhängigkeiten gar nicht sieht, sondern man hat halt
irgendwie irgendeine Pipeline, aus der fällt irgendwas raus, und der resolvt am
besten die Abhängigkeiten noch automatisiert während des Bauens und zieht
sich irgendwas aus dem Internet - das ist das eine Extrem. Und das andere Extrem ist
wieder qmail. Der hat halt überhaupt keine Abhängigkeiten, der benutzt die C-Library,
das C-Runtime, das drauf ist und braucht einen C-Compiler zum Bauen, und das war's.
Da gibt es auch ein Spektrum, was sich ja eigentlich für eine Metrik eignen würde.
Aber wie gesagt, es gibt halt mehrere Dimensionen. Wir kommen weiter. Nächste
Dimension ist Codequalität, und das ist so ein bisschen wie Security, aber ich möchte
das verallgemeinern, und zwar unter anderem deswegen, weil es eine relativ
starke Korrelation zwischen vielen Bugs und schlechter Security gibt. Alle
Security-Probleme sind auch ein Bug. Wenn jemand viele normale Bugs hat oder Bugs,
von denen wir nicht wissen oder nicht nachgewiesen haben, dass es ein
Sicherheitsproblem ist, dann ist das im Allgemeinen ein Zeichen dafür, dass da
auch viele Sicherheitslücken drin sein werden. Daher ist es wichtig als
Metrik, selbst wenn es nicht um Sicherheit geht. Wie gesagt, die Trends dazu sind
statische Code-Analyse und Code-Smells. Ich wäre noch dafür hundert Prozent
Coverage beim Unit-Testing zu erwarten. Aber das ist halt auch schwierig, weil da
gibt es verschiedene Messverfahren. Zum Beispiel: Was macht man, wenn mehr als ein
Statement auf einer Zeile steht? Was ist die Granularität des Testens?
Ja, es ist alles nicht so einfach. Aber wir sollten zumindest mal anfangen,
darüber nachzudenken.Und mein Vorschlag wäre, aus den eben erklärten Gründen, dass
wir einfach gucken, welche bekannten Bugs gibt's denn? Wie ist denn so...? Wie viele
Bugs werden bekannt, pro sagen wir mal, Jahr? Und daraus kann man extrapolieren.
Die nächste Näherung wäre, dass man alle Compiler-Warnungen anschaltet, was
erschütternd wenige Software-Hersteller machen in ihren internen Builds. Das ist
wirklich erschreckend.Und was auch viele Leute, die irgendwelche Pipelines in der
Cloud benutzen, gar nicht mitkriegen, wie viele Warnungen da eigentlich rausfliegen.
Das ist eine der wichtigsten Metriken, die ihr als Entwickler habt, und ordentlichen
Code zu produzieren. Also schmeißt Compiler-Warnungen nicht weg, lest sie und
versucht, sie weg zu machen. Und zwar nicht mit einem Pragma. Die nächste
Dimension ist: Welchen Anspruch hat der Typ überhaupt? Das ist mir aufgefallen -
es gab, ich glaube, libexiv2. Das ist so eine Software, um Metadaten in Digital-
Kamera-Bildern zu lesen. Da steht so drin, irgendwie GPS-Koordinaten und was das für
eine Linse war, und so. Und das ist halt so mehr oder weniger wohl definiert, wie dieser
Standard aussieht. Und es gibt eine OpenSource-Library dafür und da gab's es
einen Haufen Bugs drin und dann hat der Autor von dieser Software irgendwann
einfach geschrieben: "Ja, das dürft ihr halt nicht anwenden auf
unvertrauenswürdige Dateien." Das heißt, der hat nie den Anspruch gehabt, dass
das sicher ist. Aber das stand halt nicht dran, und die Leute haben seine Software
benutzt und angenommen: "Ja, der wird schon darauf geachtet haben." Daher glaube
ich, dass Erste und Beste, was wir machen können, was tatsächlich eine Auswirkung
hat, ist, wenn wir anfangen, an die Software zu schreiben, was eigentlich der
Anspruch war. Also was glauben wir, was wir erreicht haben? Was haben wir
überhaupt versucht. So das ist, glaube ich, wichtig. Eine andere Sache, die es
hier gab, war, dass Leute Features machen, die nach Sicherheit klingen. So, das war
eine Sache, die ich bei Microsoft mal erlebt habe. Da gab es eine Feature namens
"Network Access Protection", und dann bin ich da hingegangen für Thread Modelling
und wollte wissen: "Was sind eure eure Security Guarantees? Was sagt ihr denn
zu?" Und da meinten die so: "Ja, gar nichts. Wir sind kein Security-Feature."
Meinte ich so: "Ja, dann ist der Name vielleicht ein bisschen verwirrend." Aber
sowas passiert halt, weil es einen Disconnect gibt zwischen den Leuten, die
das Projekt machen, und denen, die den Namen wählen und das Marketing machen. Ja,
gut, da gibts auch nochmal Abstufungen. Es gibt halt so explorative Software.
Übrigens, fast alle Open Source Software, die ich so veröffentlicht habe, ist auch
explorativ. Das ist nicht negativ gemeint - im Gegenteil, das ist der beste Weg, wie
man Programmieren lernen kann. Ich habe etwas verstanden, wenn ich es einmal
implementiert habe. Das heißt nicht, dass die Implementation dann gut war. Das
versuche ich natürlich. Aber es ist wichtig, das zu kommunizieren: "Dieser Code
war explorativ." Der ist jetzt vielleicht gut genug abgehangen und hat genug
Real-Life-Tests gemacht und Interoperabilität, dass man ihm trauen kann. Aber der
Anspruch war explorativ. Oder es gibt dieses Szenario: "The guy left."
Das erlebt man gelegentlich bei großen Firmen. "Ja, wir haben hier noch ein Stück
Code, aber wir wissen gar nicht, wer das geschrieben hat." Oder: "Wir wissen schon,
wer das geschrieben hat, aber das war einer der Gründer, und der hat jetzt keine
Zeit mehr für sowas." Oder: "Der Typ, der ist in Ruhestand gegangen", oder
so. Das kommt alles vor. Und das finde ich aber wichtig, dass man das
kommuniziert, weil die Leute, die das benutzen, die wissen, dass halt nicht.
Oder was üblicherweise das beste Szenario ist, vom Anspruch her, ist, dass der Typ,
der das entwickelt, auch der aktuelle Maintainer ist und am Besten versucht, das
kommerziell zu vermarkten, weil der hat dann wirklich ein Interesse daran, dass es
ordentlich wird in den meisten Fällen. Gut, es gibt immer noch mehr Dimensionen,
tut mir leid, dass es so ein komplexes Problem ist.
Es gibt auch das Problem, dass der Typ,
der das umsetzt, die besten Intentionen hatte und die besten Techniken
benutzt, die es gibt, aber dass die Spec, die er umsetzt, scheiße ist. Zum Beispiel
ist XML eine Spec, die richtig scheiße ist. Da stehen Sachen drin, wie, dass man
eine Entity-Expansion machen muss, und damit kann man einen ganz trivial einen
DoS-Angriff machen - auf, im Grunde jeden standardkonformen XML-Parser. Und dann
haben die alle angefangen, irgendwie Konfiguration nachzurüsten, wo man das
ausschalten kann. Aber damit ist man eigentlich nicht mehr standardkonform.
Das kommt häufiger vor, dass Specs schlecht sind. Das ist kein Einzelfall.
Ich will jetzt nicht auf XML zeigen, andere sind auch nicht gut. Oder JSON-
Parser: Da gab es jetzt ein paar Versuche, da sind die Leute einfach herumgegangen
und haben ganz viele Rekursionstiefen aufgemacht und plötzlich platzten die
Parser alle. Oder Window-Messages bei Windows ist ein ganz altes Problem. Das
ist halt erfunden worden, bevor es mehr als einen User gab. Oder so Message-Bus
allgemein, ist so eine Sache, die häufig in so Cloud-Installationen und in großen
Firmen gesehen werden kann. Dass die Leute sagen: "Okay, wenn wir das über die
Datenbank machen, ist es zu langsam. Also bauen wir hier noch ein Message-Bus drum
rum." Und dann kann aber jeder, der Zugriff auf den Message-Bus hat,
auch spoofen oder kann alle anderen Daten sehen. Das ist die Idee schon schlecht
und es ist egal, wie gut ich das umsetze - das wird dadurch nicht
besser. Dann gibt's noch so Lock-In- Probleme. Da weiß ich nicht, ob die hier
wirklich rein gehören, aber ich finde das wichtig genug, dass, wenn wir schon dabei
sind, hier Labels zu vergeben, das auch erwähnen sollten. Zum Beispiel
irgendeine Library, die eigentlich genau das tut, was ich haben will. Aber sie
läuft nur in der Amazon-Cloud. Dann hab ich meine Freiheit, welche Plattform ich
verwende, eingeschränkt, wenn ich diese Library reinziehe. Das ist eigentlich auch
eine Sache, die man vorher kommunizieren müsste - und zwar klar. Oder bei Cryptocode
war lange Zeit ein Problem, dass der assembler-handoptimiert war für die Intel-
Architektur. Aber wenn man dann so Randgruppen-Plattformen wie
PowerPC, MIPS oder sogar ARM hatte, dann lief das halt nicht gut. Das ist jetzt ist keine
harte Abhängigkeit, aber es schränkt den Benutzer ein. Wenn wir schon
dabei sind, dann können wir auch gleich noch den Ressourcen-Footprint reinziehen.
Es gibt ja häufig so Sachen: "Ja, wir müssen hier sortieren, aber wir rechnen
nur mit zehn Elementen - also machen wir Bubbelsort." Und dann kommt jemand
und tut mehr Elemente rein und plötzlich platzt das. Das ist eigentlich
auch eine Sache, die man kommunizieren sollte: "Mit welchen Größenordnungen gehen
wir hier eigentlich um? Worauf ist das ausgelegt?" Und Achtung! Es geht nicht nur
um CPU, es geht auch um den RAM-Bedarf. Und es geht auch darum, dass zum Beispiel
eine Library ständig auf der Platte rumschreibt und I/O-Bandbreite frisst oder
versucht, aus dem Netz irgendwas nachzuladen. Also nehmen
wir mal an, das sind die Dimensionen. Es ist ein bisschen
schwierig, da eine Metrik daraus zu bauen, denn eine gute Metrik ist ja immer
zwischen 0 und 1 oder, sagen wir, 0 und 10, das heißt, man hat eine
Vergleichbarkeit. Aber wenn ich sage, wir müssen transitiv die Probleme der
Dependencies mit reinziehen, dann haben wir die Skala nicht,
weil die kann dann beliebig groß werden, wenn ich mehr Dependencies reinziehe.
Daher glaube ich, von diesem Metrik- bzw. Scoreproblem müssen wir weg. Und es gibt
das Problem, wenn ich eine Metrik habe, dass die Leute dann Gaming betreiben, um
die Metrik zu schönen und nicht das Problem zu lösen. Da dachte ich mir:
"Nennen wir es mal Legacy-Score... aber Score geht eigentlich nicht... hmm...
was kann man denn noch machen? Und vor allem wofür gilt denn die Metrik dann? Da gibt's
eigentlich auch verschiedene Ansätze, was man sagen kann..." Man könnte sagen für die
gesamte Software, dass sich so eine Art Score ausrechne. Und das ist wie, sag ich
mal, bei einer Versicherung, dass sie halt guckt, wie viel, wie wahrscheinlich ist
es, dass ich hier zahlen muss? So in der Richtung Risikobewertung. Oder ich kann
das für ein Modul machen. Oder für Manager, dass der Manager sagt:
"Das Modul ziehen wir nicht rein, das ist zu riskant." Oder für Entwickler. Oder
vielleicht sogar pro Funktion? Und da hab ich mir gedacht: "Okay, gucken wir doch
mal, was es da für Prior Art gibt, was haben die Leute denn bisher gemacht?" Und
ich habe einen schönen Standard gefunden von 1993: Kompakte Darstellung
mehrdimensioneller Daten, nämlich, den Geek Code. Wer hier kennt den Geek Code?
Das jetzt für die älteren unter euch. Das sah so aus: die Formatierung
war so ein bisschen als als Scherz auf PGP. Die Idee war, dass man sich selbst
beschreibt. Also GED heißt zum Beispiel Geek Education Sector. Und danach? Das
sind alles irgendwelche Dimensionen. Und dann eine Bewertung. Zum Beispiel: s heißt:
"Wie groß bin ich?" Und das haben die Leute in ihre Signature getan und im Usenet
verbreitet. Und dann konnte man so grob sich eine Vorstellung machen, was der
andere Typ ist, welche Interessen er hat. Ich finde das nicht gut für Typen. Das war
sozusagen der Vorgänger von Facebook könnte man aus heutiger Sicht sagen. Die
Leute haben freiwillig alles Mögliche über sich verraten. Aber die Idee ist ja
vielleicht nicht schlecht und habe ich mir gedacht: "Jetzt versuchen wir
doch mal, die Dimensionen, die ich hier formuliert habe, auf so eine Art Score
abzubilden." Und das ist gar nicht so einfach, deswegen habe ich auch den
Vortrag hier erst einmal auf deutsch gemacht, bevor ich das international
vortrage, weil ich glaube, da muss noch gefeilt werden. Ich würde mich über euer
Feedback da auch wirklich freuen, wenn ihr noch Vorschläge habt. Ich zeig jetzt mal
den Entwurf, den ich gemacht habe bisher. Die Idee wäre, dass man es als Autor
von einer Library in einen Kommentar reinschreibt, oben. Und dann hat man so
eine Art, ich sage mal, Hundepfeife. Der andere Entwickler kann es lesen und
versteht, was gemeint ist. Das hier ist jetzt noch relativ klar: "Wer besitzt
eigentlich den Code?" Und da ist der schlimmste Fall natürlich: man sieht
den gar nicht. Man hat nicht mal eine Kopie davon, sondern das läuft irgendwo in
der Cloud. Das wäre hier klar die Dimension. Dann... das ist so ein bisschen
verwandt, aber nicht genau dasselbe: "Ich habe den Code, und ich kann ihn
ändern." Oder: "Ich kann ihn nur lesen", sowas. Oder: "Der ist verloren gegangen." Oder
so das Huawei Modell: "Wir lassen die Regierung reingucken." Ja, das ist jetzt so
ein bisschen mit dem scherzenden Auge natürlich, aber ich finde die Idee
eigentlich, muss ich sagen, ganz attraktiv. Ich werde das bei meinem
eigenen Code mal einbauen. Das Problem bei sowas ist natürlich, dass man
gucken muss, dass das obere Ende auch tatsächlich das obere Ende ist und nur von
wenigen erreicht werden wird. Dass jemand tatsächlich Sicherheitszusagen macht, ist
sehr selten. Eigentlich fast nie. Dann gibt es so Leute, die machen seit 20
Jahren immer nur dasselbe. Zum Beispiel der Typ, der Zstandard macht, das so eine
Kompressions-Library, die jetzt über Facebook released wurde, der hat vorher
LZ4 gemacht und macht seit Ewigkeiten Kompressosions-Algorithmen. Da kann man
annehmen, der weiß grob, was er tut. Das geht aber runter bis zu: "Ich bin ja nicht
der Typ, der das geschrieben hat, sondern ich muss es hier nur verwalten. Ich hab
das geerbt, ich bin hier der Azubi." Das müsste eigentlich dran stehen, finde ich.
Wie sieht es denn mit der Korrektheit aus? Das ist ja auch ein Problem. Und das geht
halt von: "Ich habe einen Beweis, und den kannst du nachvollziehen." Bis über: "Ich
habe einen Beweis, und den kannst du nicht nachvollziehen." Oder: "Naja, wir versuchen
immer, alle Bugs zu schließen", wobei schließen und fixen ein Unterschied ist.
Also aufgepasst! Immer schön in den Bugtracker gucken. Und dann gibt's halt die
Leute, die argumentieren: "Ja, das ist doch gar kein Security Problem, der crasht
doch bloß." Also Leute, die entweder keine Ahnung haben oder böswillig sind. Und das
finde ich wichtig, das zu kommunizieren. Die meisten Leute sind hier bei Stand C-,
da draußen, oder sie haben überhaupt keinen Bugtracker. Das gibt's auch noch
vereinzelt. Dann hab ich mir gedacht: "Vielleicht müssen wir noch sagen:
'Welche Art von Design ist denn in die Entwicklung eingeflossen?'" Das geht halt
los mit: "Ja, alle Buzzwords angeklickt. Wir haben hier Least Privilege usw."
Dann gibt es einen relativ großen Sprung zu: "Naja, wir validieren unsere
Inputs." Das ist schon mal gut, aber es geht halt bis runter zu so
Bullshit-Blabla, von wegen: "Ja, wir haben doch einen Anti-Virus."
*Publikum lacht*
Und ich finde, das wäre eigentlich schön, wenn man es an der Software hätte. So eine
Art Label. Die Idee kam mir eigentlich, als ich mal in Amerika so eine
Multi-Vitamin-Tabletten-Packung gekauft habe, denn da ist hinten so eine riesige
Tabelle drauf, mit den Supplement Facts und da steht drauf: "Dieses Vitamin, so
und so viel Prozent der Recommended Daily Allowance." Und da kann man dann sehen:
"Okay, die wollen mich verarschen." Weil da steht dann sowas wie: "Vitamin C: 5000%"
So: "Viel hilft viel." Also ich meine, da muss man natürlich trotzdem, als
der, der dieses Label liest, ein grobes Verständnis haben, was das bedeutet. Aber
immerhin. Ich glaube, das ist ein Weg, den wir mal ausprobieren können. Übrigens das
hier unten: "The author left" und "project abandoned" ist häufiger, als man glaubt.
Volatility: das versucht, so ein bisschen dieses Agilitätsproblem
anzugehen. Dass Leute einfach häufiger releasen, als man prüfen kann, ob das
jetzt ordentlich ist oder nicht. Aber so richtig eine gute Lösung gibt es
eigentlich nicht. Was ich so persönlich als am entspanntesten empfinde, ist Vim.
Vim bringt im Grunde täglich Updates raus, aber man merkt nie, dass sich irgendwas
verändert hat. Weil die Software compiled vorher und nachher, alle Sachen, die ich
benutzt habe, gehen noch. Das ist, glaube ich, das Optimalziel, was man da erreichen
kann bei Software, dass der Kunde gar nicht merkt, ob gepatcht wurde oder nicht,
weil das einfach alles weiter funktioniert. Die Spec hatte ich ja schon
erwähnt. Die müssen wir auch irgendwie abbilden, ob die Spec was taugt. Und da
gibt es auch ein großes Spektrum: Dass die Spec offen, kurz und verständlich ist, ist
leider auch selten. Häufig kommt es vor, dass die Spec hinter einer Paywall ist,
und das ist dann so gut, als wenn es gar keine Spec gäbe, weil ich als Open-Source-
Typ werde jetzt nicht zur ISO laufen und mir für ein paar tausend Euro irgendwie
die MPEG-Spec runterladen um zu gucken, ob der MPEG-Player ordentlich ist, den ich da
gerade runtergeladen hab. Dann haben wir noch Dependecies. Das müsste man
eigentlich transitiv machen, da ist mir jetzt auch nicht klar, wie man das auf den
Score abbildet. Wenn einer von euch eine Idee hat, bin ich da gerne für zu haben.
Also wie sieht das in der Praxis aus? Ich habe hier mal versucht, ein paar
Beispiele zu machen - ungefähr so. Das Problem ist halt, dass die Dimensionen
jeweils auf beiden Seiten subjektiv sind. Das heißt, für den einen oder anderen ist
es vielleicht okay, wenn er den Quellcode nicht hat, solange es noch Wartungen gibt.
Also Leute, die Windows einsetzen, zum Beispiel. Für die ist es okay,
wenn es den Quellcode nicht gibt. Aber das heißt eben, dass der
Score auch nicht einfach eine Zahl sein kann, sondern er muss pro Dimensionen
einen Wert haben. Das sieht jetzt irgendwie schwer zu lesen aus - und ist es auch.
Aber bei dem Geek Code hat sich herausgestellt: wenn man so ein paar Tage
macht, dann gewöhnt man sich dran. Und ich glaube, das ist eine ganz gute Idee. Ich
hab mir dann noch überlegt: "Eigentlich brauchst du jetzt noch eine schöne Domain."
Habe mir überlegt: "legacyco.de wäre super!", aber die hat schon Xing gekauft.
*Publikum lacht*
Ja gut, das war so mein Vorschlag. Ich hoffe, ich kriege jetzt eine Menge gute Ideen,
was man da noch verbessern kann oder vielleicht auch andere Vorschläge, die
keinen Score beinhalten. Vielleicht ist ja auch der ganze Ansatz schon falsch. Aber
ich bin mir sicher, dass wir als Industrie jetzt mal loslegen müssen. Ich glaube,
reaktiv funktioniert das nicht, sondern wir müssen gucken, wie wir im
Entwicklungsprozess erstens dafür sorgen, dass die Leute die Entscheidungen, welche
Produkte sie reinziehen, welche Dependencies sie reinziehen, auf
informierter Grundlage treffen können. Ich hätte gern, dass es so einen Score gibt,
wo man dann auch als Entwickler einen Anreiz hat, das besser werden zu lassen,
weil man sehen kann: "An der Stelle bin ich noch nicht der Standard,
der ich sein möchte." Ansonsten, wir haben jetzt die
Saal-Mikrofone. Ich hoffe, die Signal- Engel sind schon so weit. Ansonsten, Fragen
nehme ich auch gern per Mail entgegen. Vielen Dank für die Aufmerksamkeit.
*Applaus*
Herold: Dann können jetzt alle an die Mikrofone gehen, die noch Fragen haben.
Wir haben direkt eine Frage aus dem Internet. Bitte!
Anonym: Gibt es Projekte im echten Leben, wo das Problem mit der Komplexität deiner
Meinung nach richtig gemacht wurde? Und wenn ja, wo findet man die?
Fefe: Sehr selten. Es gab einmal vor ein paar Jahren gab es so einen Push,
wo viele Leute angefangen haben, Software zu veröffentlichen und damit zu bewerben,
dass sie besonders klein oder minimal sein soll. Da bin ich auch einer von. Aber es
stellt sich halt raus, dass es auch andere Projekte gibt, die halt minimal dran
schreiben, weil sie finden, es sei minimal, und das ist dann aber nicht
minimal. Zum Beispiel gab es neulich ein Announcement von einem Systemd-Clone in
Rust, und ich bin eigentlich ein Fan von Rust und kein Fan von Systemd. Deswegen
fände ich da ein Ersatz schon gut. Aber Rust erzeugt keine kleinen
Binaries, sondern da fallen so große Monster raus. Das heißt, das ist dann zwar
minimal im Sinne von, wie viel Features es implementiert, aber das Endprodukt ist
halt riesig groß. Da kann jetzt der Typ nichts für, der das geschrieben hat. Das
ist im Moment noch ein Rust-Problem, und da arbeiten die auch dran.
Aber "minmal", "Komplexität", "gering", ist eine subjektive Sache. Ich
persönlich habe immer die Software von Dan[iel] Bernstein sehr gut gefunden, also
qmail und djbdns sind gute Beispiele dafür, wie ein Code aussieht, der
Komplexität gut managed und klein hält. Aber es ist ein kleines Feld. Man findet
da nicht so viele Beispiele von Software, die gut gemacht und unterkomplex ist.
Herold: Dann, am Mikrofon 10 hatte ich gesehen. Kann das sein? Ich habe gerade
ein Signal bekommen... Nein? Alles klar. Da machen wir weiter mit Mikrofon zwei.
Bitte! Anonym: Vielen Dank für die spannenden
Ideen! Meine Frage geht so ein bisschen auf: Ist das nicht zu freiwillig und zu
selbst auferlegt? Ist das nicht zu CDU- mäßig als Lösung?
*Fefe lacht* Was hält nicht davon ab, einfach zu sagen
Ich bin M+++, obwohl ich das vielleicht gar nicht bin?
Fefe: Das ist in der Tat ein Problem, und ich bin mir auch nicht sicher, wie und ob
man das lösen kann. Ich glaube aber, wenn man anfängt und das so ein bisschen
losgeht, dass es dann auch ein Druck gibt aus der Community, der die Leute davon
abhält zu lügen. Also meine Erfahrung mit Entwicklern ist, dass die meisten Leute
eigentlich gute Menschen sind. Die möchten keinen Scheiß machen, niemand
möchte lügen. Das heißt, wenn du denen eine Gelegenheit gibst darzustellen, dass
das noch nicht fertig ist, dann werden sie das auch tun, im Allgemeinen. Außer du
hast jemanden, der es wirklich nicht beurteilen kann. Das Risiko kriegst du mit
dem Label nicht weg. Aber ich glaube, es ist schon mal ein guter Schritt, wenn wir
den den Entwicklern, die gerade dabei sind, sich eine Dependancy ins Projekt zu
ziehen, irgendwas in die Hand geben, woran sie erkennen können: "Ist das denn jetzt
ernst gemeint, oder war das hier nur so ein Spielprojekt?" Und ich glaube, das ist
ein guter Anfang. Aber ich weiß es natürlich auch nicht. Müssen wir
ausrollen, müssen wir gucken. Herold: Dann am Mikrofon 6, war zuerst.
Anonym: Das geht vielleicht auch jetzt in dieselbe Richtung wie der Fragende vor
mir. Vielleicht. Könnte man wie so eine Art Rechtsprechungs-Instanz installieren?
Ich meine, kein Entwickler-Team aus Indien wird das als Malus akzeptieren, wenn da
dran steht: Entwickler-Team in Indien hat jetzt das gemacht. Hältst du das für eine
sinnvolle Idee? Wie könnte man das umsetzen?
Fefe: Also es ging jetzt nicht um Indien, das hätte auch Massachusetts sein können,
sondern es geht darum, dass das Team halt nicht der ist, der das geschrieben hat,
sondern irgendjemand hat es jetzt halt am Bein, weil wir brauchten einen Maintainer.
Das ist immer ein Problem. Und natürlich wird es auch irgendwie Betrüger geben.
Aber ich hoffe, dass man die dann erkennt, weil die halt in allen Feldern das Beste
jeweils anklicken. Aber ich weiß es halt auch nicht, das muss man ausprobieren.
Also meine Erfahrung ist, dass an anderer Stelle Communities schon helfen, den
Standard hochzuziehen, wenn man zumindest einfach mal anfängt und sagt: "Das
hier ist wichtig, da müssen wir drüber reden." Und das ist, glaube ich, ein
Zeichen, wenn es so einen Code gibt, wo es ein Feld gibt, für: "Wie volatil ist denn
das?", und supervolatil ist nicht der höchste Score, dass man vielleicht
irgendwie auf die Art auch Ideen transportiert kriegt? Dass man sagt:
"Vielleicht musst du nochmal drüber nachdenken, wie du dein Projekt aufziehst."
Herold: Dann bitte am Mikrofon 1. Anonym: Ich hab grad drüber
nachgedacht, ob das nicht so etwas ähnliches ist, wozu die
Lebensmittelindustrie so ein bisschen genötigt werden musste: Alle Inhaltsstoffe
reinzuschreiben, Allergene reinzuschreiben und so. Und deshalb die Frage: Sollten wir
nicht möglichst bald als Follow-Up entwickeln, so eine Art Software Code-
Ampel einzuführen. Und dann rot, gelb und grün daraus zu machen.
*Lacht* Fefe: Ja, genau. Das war ja eigentlich die
Idee. Aber ich glaube, du kannst es nicht runterbrechen auf einen Score, weil
einige Teile davon subjektiv sind. Das ist ja bei Lebensmitteln eher nicht so,
sondern da vertraust du der Behörde. Die Behörde sagt irgendwie so und so viel
Quecksilber ist Maximum. Und wenn mehr, ist es nicht gut. Da fängst du nicht
an zu verhandeln. Aber wenn jetzt die Software kommt und sagt: "Wir ziehen
hier noch ein MySQL rein", und du weißt es nicht besser, dann sagst du halt:
"Okay". Das ist eine Sache, die muss man auch dem Endbenutzer überlassen. Weil du
willst ja auch nicht, zum Beispiel, OCaml benachteiligen, weil
da noch keiner von gehört hat. Und dass die Leute sagen: "Ja wie, da gibts jetzt
keinen Score für?" Das ist halt nicht C. Ist es jetzt besser oder nicht? Das
muss ja offen genug bleiben. Deswegen glaube ich auch nicht an Schiedsgerichte
und irgendwie Organisationen, die Labels vergeben. Das ist doch nie gut
ausgegangen, in meiner Erfahrung. Ich glaube, das muss aus der Community kommen,
und das muss so laufen, dass man das Gefühl hat, ich tue jetzt hier etwas
Besseres, und ich kann den Erfolg sehen, weil mein Score jetzt hier besser wird.
Ich kann jetzt hier ++ schreiben. Ist jetzt die Hoffnung. Ich weiß auch nicht,
ob es geht. Herold: Dann bitte nochmal Mikrofon 2.
Anonym: Mir hat eine Dimension gefehlt, die ein bisschen in Wartungen passt, aber
nicht perfekt. Wir sind ja hier ein Raum voller Leute, die Sachen selbst in die Hand
nehmen. Wie leicht ist es denn mitzumachen? Wie leicht ist es Bugs selbst
im Upstream zu fixen? Muss man erstmal einen Vertrag unterschreiben, wo man alle Rechte
abtritt, oder? Das ist, glaube ich, auch noch eine wichtige Dimension.
Fefe: Das stimmt. Ich habe das versucht abzubilden, über den: "Ich hab den Code
und darf ihn ändern." Aber das Problem ist, dass das derjenige, der das Projekt
verwaltet, üblicherweise nicht gut beurteilen kann, sondern der wird immer
sagen: "Ja, ist alles total offen hier". Das geht, glaube ich, nicht über so einen
Score. Aber man kann es natürlich versuchen.
Herold: Dann bitte Mikrofon 8. Anonym: Ist fehlendes IPv6 für dich ein
Bug oder ein nicht implementiertes Feature?
Fefe: Das ist eine der subjektiven Fragen. Für mich persönlich ist es ein Fehler,
wenn kein IPv6 drin ist. Aber es gibt genug Firmen da draußen, die sagen: "Das
haben wir eh nicht." Anonym: Danke.
Herold: Dann bitte Mikrofon 7. Anonym: Die Intention, dass die Community
das schon richten wird. Du hattest CVSS als relativ positives Beispiel
dargestellt. Vor fünf Jahren war Heartbleed in OpenSSL, das hat einen CVSS-
Bug von 5,0 gehabt, und Bruce Schneier kommentierte: "Auf einer Skala von 1 bis 10
ist das Wert 11." CVSS ging gerade bis 10. Ich sehe nicht, dass das so klappen kann,
und ich finde es gut, dass du aufgezeigt hast, wie komplex das ist, denn wir haben
halt keinen Standard. Was bedeutet denn zum Beispiel eben "minimal"? Oder wenn eine
Zwei-Faktor-Authentifizierungs-Umgehung ein Sicherheitsbug ist, ist dann jede
Anwendung mit einer Ein-Faktor- Authentifizierung automatisch ein
Sicherheitsbug? Fefe: Ja, du hast völlig recht, das sind
offene Forschungsfragen, wie man das lösen soll. Ich habe da auch keine
guten Antworten. Die die Heartbleed Sache hätte man vielleicht klären können, indem
man sagt: "Welche Zusagen machen wir denn?" Wenn die Zusagen gebrochen sind,
dann ist automatisch Totalschaden. Aber wir haben halt häufig - ich habe das ja auf
einer Folie gehabt - Projekte, die klingen so, als wenn sie ein
Security Feature implementieren. Und wenn du sie dann fragst, welche Zusagen sie
machen, kommt dann halt: "Ja ne, gar keine. Wer mich einsetzt, ist selber
schuld." Und da müssen irgendwie von wegkommen. Ich glaube, das geht nur, wenn
man bei den Leuten so ein bisschen das Empfinden schärft dafür, dass sie gerade
die Legacy von morgen schreiben. Die Leute tun immer so, als wenn Legacy vom Himmel
fällt. Das haben wir geerbt. Ne, du schreibst gerade halt nicht von heute die
Legacy, sondern die von morgen. Herold: Dann gab es noch eine Frage aus
dem Internet, bitte! Anonym: Ja, bei deinem Bewertungsschema:
Wie soll das bei Projekten funktionieren, bei denen es gar keinen Owner mehr gibt,
der das dranschreiben könnte? Fefe: Naja, irgendwann, wenn sich das gut
genug durchsetzt, ist die Abwesenheit eines Labels an sich schon ein schlechtes
Zeichen. Aber das wird natürlich ewig dauern, bis wir so weit sind. Also ist nur
ein Ansatz. Das kann ich auch nicht lösen. Wenn es niemanden gibt, der das Label dran
klebt, kann man vielleicht irgendwie eine Community-Entscheidung auf GitHub machen.
Eine Verurteilung durch den Mob? *Lachen*
Herold: Dann bitte am Mikrofon 4. Anonym: Das sind jetzt doch relativ grobe
Kategorien. Und gerade bei Enterprise Software als Entwickler wirst du es jetzt
schwer schaffen, irgendwie bei "Lizenz" eine Kategorie hochzukommen. Ist denn deine
Hoffnung, dass tatsächlich Entwickler dazu angeregt werden, existierende Software zu
verbessern oder mehr in die Richtung, wenn ich jetzt eine neue Software mach, dass
ich mir mal Gedanken mach: "Was will ich überhaupt erreichen und was für Garantien
gebe ich?" Fefe: Das richtet sich vor allem an
Hobbyisten im Moment, weil im Enterprise Umfeld sind die sind die Einschränkungen
der Umgebung andere. Da wirst du halt bezahlt von der Firma. Und der Typ, der
dich bezahlt, entscheidet, wofür du deine Zeit ausgibt. Und da hast du gar nicht die
Option, jetzt rumzulaufen und den alten Code besser zu machen, weil es einen
riesigen Backlog an Sachen gibt, die du noch machen musst. Besonders so in Agile
Umfeldern wird ja sozusagen jede freie Minute noch rausoptimiert. Und da stellt
sich die Frage gar nicht, ob ich jetzt rumlaufe und alten Code besser mache.
Daher glaube ich, wir müssen über Open Source kommen, und da hätte ich früher
nicht viel Hoffnung gehabt. Aber Open Source hat gewaltigen Einfluss ausgeübt
auf Enterprise Umgebung. Das merkt man vielleicht aus der Open Source Seite noch
nicht so. Aber wenn du in Enterprise Umgebungen unterwegs bist. Fast alle
größeren Projekte sind alle irgendwie internetbasiert inzwischen. Selbst
Appliances haben alle Internet, und das ist dann zu bestimmt
60-80% Open Source, je nachdem, in welcher Branche man da unterwegs ist. Open
Source hat einen großen Einblick, und als Open Source anfing zu sagen: "Okay, wir
müssen agile werden", hat Enterprise nachgezogen. Daher, glaube ich, werden wir
es schaffen, als Open Source hier Standards zu setzen, dass es auch in
Enterprise rüberschwappt, das ist die Hoffnung...
*36C3 Musik*
Untertitel erstellt von c3subtitles.de im Jahr 2020. Mach mit und hilf uns!