36C3 - Das nützlich-unbedenklich Spektrum

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!