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!