WEBVTT
00:00:00.000 --> 00:00:18.751
36C3 Intro Musik
00:00:19.571 --> 00:00:23.300
Herald: Jetzt mit dem Talk 'Das nützlich-
unbedenklich Spektrum' Ich muss ihn, wie
00:00:23.300 --> 00:00:26.625
gesagt, nicht vorstellen: Fefe.
00:00:26.625 --> 00:00:30.482
Applaus
00:00:30.482 --> 00:00:31.482
Mikrofonklopfen
00:00:37.082 --> 00:00:40.110
Fefe: Ja guten Morgen. Freut mich, dass
das alles hier so voll ist. Ein Glück,
00:00:40.110 --> 00:00:44.340
dass das hier nicht Halle 1 ist. Das wäre
ja schlimm, so viele Leute. Ja, dieser
00:00:44.340 --> 00:00:46.770
Vortrag, ich muss gleich ein bisschen
Erwartungsmanagement machen. Ich habe
00:00:46.770 --> 00:00:50.820
nämlich eigentlich letztes Jahr einen
anderen Vortrag eingereicht über TCB-
00:00:50.820 --> 00:00:54.240
Minimierung und das wäre so ein bisschen
technisch gewesen. Was man denn machen
00:00:54.240 --> 00:00:59.670
kann als Programmierer. Der ist abgelehnt
worden. Ich weiß nicht, warum. War voll.
00:00:59.670 --> 00:01:02.520
Den habe ich dieses Jahr wieder
eingereicht, aber es sollte nicht so
00:01:02.520 --> 00:01:05.520
aussehen, als wenn ich die ärgern will,
also habe ich noch einen Talk eingereicht.
00:01:05.520 --> 00:01:10.800
Den haben die natürlich genommen.So, das
heißt, den musste ich jetzt schnell
00:01:10.800 --> 00:01:12.810
vorbereiten.
Publikum lacht
00:01:13.320 --> 00:01:19.290
Ja, das Problem ist, das ist eher so ein
Gedankengang als eine strukturierte
00:01:19.290 --> 00:01:23.490
Darstellung. Ich hoffe, es wird trotzdem
hilfreich. Aber es ist nicht so
00:01:23.490 --> 00:01:27.720
strukturiert wie meine sonstigen Vorträge.
Ich fange einfach mal an. Also es gibt
00:01:27.720 --> 00:01:32.310
mehrere Herleitungen, die im Grunde zum
selben Ergebnis führen und ich lasse euch
00:01:32.310 --> 00:01:36.540
einfach mal teilhaben.Es fing relativ früh
in meiner Karriere an, da habe ich mich
00:01:36.540 --> 00:01:40.980
entschieden: ich werde nie Software
schreiben, von der vielleicht Leben
00:01:40.980 --> 00:01:45.780
abhängen könnten, so medizinische Geräte,
Atomkraftwerke, war so meine Vorstellung,
00:01:45.780 --> 00:01:51.120
Militär natürlich sowieso nicht. Und dann
habe ich aber jemanden getroffen, der Code
00:01:51.120 --> 00:01:54.450
für Atomkraftwerke schreibt. Und das war
so ein Typ: "Ey das ist doch ganz
00:01:54.450 --> 00:02:00.300
einfach." Das heißt, wenn die Leute, die
ihre Grenzen einschätzen können, das nicht
00:02:00.300 --> 00:02:03.660
machen, dann machen es halt die anderen.
Publikum lacht
00:02:04.630 --> 00:02:08.980
Das soll jetzt nicht verallgemeinernd sein.
Ich habe tatsächlich noch einen anderen
00:02:08.980 --> 00:02:12.160
getroffen, der war nicht so, aber ich
meine, diese Art von Personen gibt es
00:02:12.160 --> 00:02:18.220
halt. Die Problematik an der Stelle ist,
glaube ich, dass man Programmieren
00:02:18.220 --> 00:02:23.350
explorativ lernt: das ist häufig nicht so
einen Kurs, den man durchgeht, sondern man
00:02:23.350 --> 00:02:28.690
läuft halt rum und sucht Grenzen. Das
heißt aber auch, dass man per Definition
00:02:28.690 --> 00:02:33.160
die Grenzen noch nicht kennt, denn die
will man ja gerade finden. Das heißt aber
00:02:33.160 --> 00:02:38.260
auch, dass alle Leute im Grunde immer
gerade an ihrer Grenze arbeiten. Wenn
00:02:38.260 --> 00:02:41.200
Leute Software schreiben, dann gehen sie
so weit, wie sie glauben, dass sie gerade
00:02:41.200 --> 00:02:47.320
noch können. Und das heißt aber im
Umkehrschluss, dass die Technologie, die
00:02:47.320 --> 00:02:50.530
da draußen ausgerollt wird, das sind
hauptsächlich eben nicht abgehangene
00:02:50.530 --> 00:02:55.240
wohlverstandene Sachen, sondern das sind
genau die Technologien, die der Typ gerade
00:02:55.240 --> 00:03:01.450
noch verstanden hat. Das ist so ein
bisschen ein Problem, und das wird nochmal
00:03:01.450 --> 00:03:04.660
verstärkt dadurch, dass wir eben heute so
eine Modularisierungs- und
00:03:04.660 --> 00:03:09.460
Abhängigkeitswelle haben, dass Leute
einfach noch Module von anderswo mit
00:03:09.460 --> 00:03:16.540
reinziehen und sich einfach im Grunde ohne
Grundlage in der Realität vorstellen, dass
00:03:16.540 --> 00:03:20.650
derjenige schon wissen wird, was er tut.
Und so ist es eben häufig nicht, sondern
00:03:20.650 --> 00:03:25.480
das sind genau so Leute wie du und ich,
die eben auch explorativ gearbeitet haben.
00:03:25.480 --> 00:03:30.070
Das kann man sich auch ganz gut selbst
überlegen, wenn man so ein kurzes
00:03:30.070 --> 00:03:34.210
Gedankenexperiment macht. Das konnte man
auch schon live beobachten. Also nehmen
00:03:34.210 --> 00:03:37.840
wir mal an, jemand findet einen Weg, um
besser mit Komplexität umzugehen. Zum
00:03:37.840 --> 00:03:41.200
Beispiel Modularisierung oder
objektorientierte Programmierung, als das
00:03:41.200 --> 00:03:44.770
gerade frisch war. Und dann würde man ja
hoffen, dass wir die Software, die wir
00:03:44.770 --> 00:03:47.560
davor geschrieben haben, jetzt besser
machen, weil wir das besser im Griff
00:03:47.560 --> 00:03:51.100
haben. Aber das passiert halt nicht,
sondern was passiert ist, dass wir dann
00:03:51.100 --> 00:03:57.220
eben größere Software schreiben und wieder
am Limit arbeiten. Ich glaube, dass das
00:03:57.220 --> 00:04:00.400
kein Problem der Softwareentwicklung oder
des Programmierens ist, sondern generell
00:04:00.400 --> 00:04:03.790
ein Problem mit Menschen. So hat uns die
Evolution gemacht, und da müssen wir
00:04:03.790 --> 00:04:07.820
lernen mit umzugehen. Und ich will das mal
illustrieren: Ich habe so eine Theorie,
00:04:07.820 --> 00:04:14.870
die nenne ich die Gradienten-Theorie. Die
These ist, dass Menschen ihre Umgebung wie
00:04:14.870 --> 00:04:18.110
ein Optimierungsverfahren betrachten in
der Mathematik. Das heißt, man hat
00:04:18.110 --> 00:04:22.850
sozusagen ein Gelände und sucht den
höchsten oder tiefsten Punkt - das ist so
00:04:22.850 --> 00:04:29.360
ein Optimierungsproblem. Und dabei geht
man eben nicht gezielt vor, wenn man das
00:04:29.360 --> 00:04:34.280
Gelände nicht kennt, sondern man muss
Annahmen treffen, und das kann man an sich
00:04:34.280 --> 00:04:37.490
selbst beobachten. Wenn es zu kalt ist,
dann geht man ja zur Heizung und stellt
00:04:37.490 --> 00:04:41.510
nicht so ein, wie man es haben will,
sondern man stellt heiß, und dann wartet
00:04:41.510 --> 00:04:44.390
man, bis es zu warm wird, und dann geht
man wieder hin und stellt wieder runter.
00:04:44.390 --> 00:04:47.510
Das heißt, wir haben so ein
Annäherungsverfahren, wie wir mit der Welt
00:04:47.510 --> 00:04:50.030
umgehen. Und das ist nicht nur bei
Heizungen. Das ist auch beim Autofahren,
00:04:50.030 --> 00:04:53.840
wenn wir so eine Landkarte haben, dann
gucken wir uns an, was ist denn das Limit?
00:04:53.840 --> 00:04:58.730
Wo müssen wir abbiegen? Und den Weg dahin
ignorieren wir, obwohl der vielleicht ganz
00:04:58.730 --> 00:05:03.410
schön ist. Viele Sachen, die wir machen,
auch die Geschwindigkeitsauswahl, ist so
00:05:03.410 --> 00:05:06.320
ein Gradienten-Ding Wir beschleunigen, bis
wir uns unwohl fühlen. Dann gehen wir
00:05:06.320 --> 00:05:11.390
wieder ein bisschen zurück. Oder wenn man
im Wörterbuch oder Telefonbuch
00:05:11.390 --> 00:05:15.785
nachschlägt, dann macht man eine Annahme,
wo das ungefähr sein wird. Und wenn das zu
00:05:15.785 --> 00:05:19.070
weit ist, geht man wieder zurück. Also der
elementare Teil ist jedenfalls: wir haben
00:05:19.070 --> 00:05:22.580
die Annahme, dass das Gelände ungefähr so
aussieht. Wir haben hier eine glatte
00:05:22.580 --> 00:05:26.480
Übergänge, und dann funktioniert das
Verfahren gut. Das heißt Gradient Descent
00:05:26.480 --> 00:05:29.930
übrigens, dass man versucht, der
Schwerkraft hinterherzulaufen und den
00:05:29.930 --> 00:05:34.490
tiefsten Punkt zu suchen. Aber es
funktioniert in zwei Fällen eben nicht
00:05:34.490 --> 00:05:38.090
gut: Der eine ist, wenn es einen Abhang
gibt, über den ich rüberlaufe und dann
00:05:38.090 --> 00:05:41.930
kann ich nichts zurück korrigieren. Und
das läuft auch nicht gut, wenn man nicht
00:05:41.930 --> 00:05:46.400
merkt, wenn man zu weit gegangen ist. Also
ist so ähnlich wie der Abhang, und das
00:05:46.400 --> 00:05:49.970
zweite Problem ist, wenn man nicht
zurückrollen kann, aus anderen Gründen.
00:05:49.970 --> 00:05:53.810
Die gibts in der Softwareentwicklung eben
häufiger, und es stellt sich heraus, sind
00:05:53.810 --> 00:05:58.340
genau die Art von Problemen, die Menschen
haben. Zum Beispiel, wenn wir so was haben
00:05:58.340 --> 00:06:03.430
wie zwei Wochen Probeabo, dann vergessen
die Leute halt, da wieder auszutreten,
00:06:04.030 --> 00:06:09.580
oder Drogenabhängigkeit ist ein Klassiker,
Spielesucht. Und in der
00:06:09.580 --> 00:06:12.370
Softwareentwicklung oder überhaupt im
Projektmanagement ist es häufig: Jetzt
00:06:12.370 --> 00:06:17.260
haben wir schon so viel investiert, jetzt
können wir nichts zurück. Security ist
00:06:17.260 --> 00:06:22.240
kein Gradient, es sieht vielleicht aus wie
ein Gradient, aber es ist keiner. Das ist
00:06:22.240 --> 00:06:26.800
gerade, glaube ich, das Grundproblem von
der IT-Security. Man merkt nicht, wenn man
00:06:26.800 --> 00:06:30.640
zu weit gegangen ist. Das merkt man erst,
wenn man gehackt wird. Und dann kann man
00:06:30.640 --> 00:06:35.020
nicht mehr zurückrollen. Dann sind die
Daten schon weg. Komplexität ist ähnlich
00:06:35.020 --> 00:06:38.260
wie Security auch kein Gradient, aber es
fühlt sich an wie einer. Und das ist,
00:06:38.260 --> 00:06:42.130
glaube ich, der Grund, warum wir damit so
schlecht umgehen können. Das fühlt sich
00:06:42.130 --> 00:06:45.130
an, als würden wir alles unter Kontrolle
haben. Und zu dem Zeitpunkt, wo wir
00:06:45.130 --> 00:06:50.140
merken, dass es nicht mehr so ist, können
wir nicht mehr zurück. Übrigens ist auch
00:06:50.140 --> 00:06:54.820
Daten rausgeben so an Facebook oder so ist
genauso ein Pseudo-Gradient, nenne ich das
00:06:54.820 --> 00:07:00.550
mal. Zu dem Zeitpunkt, wo man merkt, dass
man zu viel rausgegeben hat, ist es zu spät.
00:07:00.550 --> 00:07:05.650
So die Schlussfolgerung ist eigentlich:
Komplexität ist böse. Wir bemerken sie zu
00:07:05.650 --> 00:07:09.610
spät und wir fangen sie uns auch zu leichtfertig
ein. Und da muss man halt irgendwie
00:07:09.610 --> 00:07:14.680
gegensteuern. Die Kosten dafür werden im
Moment an unsere Kunden, wenn wir das
00:07:14.680 --> 00:07:19.480
beruflich machen, externalisiert, an
unsere Benutzer und an unser zukünftiges
00:07:19.480 --> 00:07:24.700
Selbst. Daher findet man relativ selten
glückliche ältere Softwareentwickler.
00:07:24.700 --> 00:07:28.901
Publikum lacht
So, das war der erste Gedankengang, der
00:07:28.901 --> 00:07:32.786
mich in die Richtung geführt hat. Der
zweite Gedankengang: Ich will jetzt mal
00:07:32.786 --> 00:07:35.854
das GNU Manifesto herausgreifen.
Stellvertretend. Das ist kein GNU-Bashing
00:07:35.854 --> 00:07:39.484
hier, aber am GNU Manifesto kann man das
ganz gut zeigen. Das war die ursprüngliche
00:07:39.484 --> 00:07:43.647
Ankündigung des GNU-Projekts von Richard
Stallman. Da hat er geschrieben: "Wir
00:07:43.647 --> 00:07:47.939
machen Unix-Programme, und wir werden aber
nicht genau dasselbe sein wie Unix. We
00:07:47.939 --> 00:07:53.041
will make all improvements that are
convenient." Das ist ein ganz furchtbarer
00:07:53.041 --> 00:07:58.473
Satz. Was heißt denn 'convenient', für wen
denn? Aber das ist genau die
00:07:58.473 --> 00:08:03.258
Herangehensweise, die viele Leute haben,
die Software schreiben: "Oh, das können
00:08:03.258 --> 00:08:07.281
wir noch schnell dazutun." Was fehlt, ist
so ein Korrektiv, dass man vorher drüber
00:08:07.281 --> 00:08:11.304
nachdenkt: "Was hänge ich mir eigentlich
gerade für eine Legacy ans Bein?" Ich
00:08:11.304 --> 00:08:15.766
glaube dieser Convenience-Gedanke beim
Erweitern von Software ist unsere Erbsünde
00:08:15.766 --> 00:08:20.010
- um hier mal ein bisschen katholisch zu
werden - in der Softwareentwicklung. Die
00:08:20.010 --> 00:08:24.252
haben alle schon einmal begangen und das
kriegt man eben nicht nachkorrigiert.
00:08:24.252 --> 00:08:27.256
Daher ist der einzige Weg, das
loszuwerden, wenn man die ganze
00:08:27.256 --> 00:08:31.626
Software oder das ganze Modul wegschmeißt
und neu macht. Aber Software stirbt halt
00:08:31.626 --> 00:08:36.592
nicht. Ich habe im Umgang mit Software
erst verstanden, dass es gut ist, dass
00:08:36.592 --> 00:08:40.508
Menschen sterben, weil das ist ein
Korrektiv, was gebraucht wird. Wenn System
00:08:40.508 --> 00:08:44.026
besser werden soll, dann muss der alte
Scheiß auch irgendwann sterben können. Und
00:08:44.026 --> 00:08:49.584
das passiert bei Software halt nicht. Es
ist ein Feature, dass Dinge nicht ewig
00:08:49.584 --> 00:08:55.269
halten. Man kann das allgemein beobachten,
wenn jemand seine Software erweitern will
00:08:55.269 --> 00:08:58.484
und er hat die Wahl zwischen "Wir machen
jetzt hier mal was, um das konkrete
00:08:58.484 --> 00:09:01.905
Problem zu lösen" oder "Wir machen hier
was, um ein allgemeineres Problem zu
00:09:01.905 --> 00:09:06.636
lösen." Dann werden die Leute immer das
allgemeinere Problem zu lösen versuchen.
00:09:06.636 --> 00:09:12.057
Viel Feind, viel Ehr. Und das kann man
fast flächendeckend beobachten. Es gibt
00:09:12.057 --> 00:09:16.859
sehr wenige Ausnahmen davon. Und ich hatte
meinen Aha-Moment, als ich eines Tages mal
00:09:16.859 --> 00:09:21.215
gdb aufgerufen habe auf ein Projekt, also
ich habe jetzt hier /tmp genommen, aber
00:09:21.215 --> 00:09:26.135
das Projekt war irgendein Checkout. Ich
habe in meinem eigenen Webserver
00:09:26.135 --> 00:09:30.507
einen .gdbinit. Das ist eine Konfig-Datei
für den GNU-Debuger, wo man zum Beispiel
00:09:30.507 --> 00:09:33.405
sagen kann: "Ruf das Programm, wenn ich es
debuggen will, mit diesen
00:09:33.405 --> 00:09:36.808
Kommandozeilenargumenten auf!" Und da
schreibe ich dann rein: "Nimm nicht Port
00:09:36.808 --> 00:09:41.393
80, weil das klappt nicht, sondern nimm
Port irgendwie 8005 oder so, was-weiß-ich,
00:09:41.393 --> 00:09:46.097
halt localhost zum debuggen." Und gdb hat
eines Tages angefangen zu sagen: "Nee, die
00:09:46.097 --> 00:09:50.553
.gdbinit-Datei, die nehme ich aber nicht,
denn die liegt hier in einem Verzeichnis,
00:09:50.553 --> 00:09:56.000
was du nicht freigeschaltet hast." Und das
war genau so ein Versuch, diesen Fehler
00:09:56.000 --> 00:10:01.097
nach Werk, nach der Tat zu korrigieren.
gdb hat festgestellt: "Unsere Konfig-Datei
00:10:01.097 --> 00:10:05.810
ist so mächtig geworden, dass es ein
Sicherheitsproblem darstellt", und hat dann
00:10:05.810 --> 00:10:11.038
halt die ganze Konfig-Sache zugenagelt für
rückblickend. Und das hat halt mehr
00:10:11.038 --> 00:10:15.686
kaputtgemacht, als nötig gewesen wäre -
vielleicht, weiß ich nicht - aber es war
00:10:15.686 --> 00:10:19.270
für mich sehr ärgerlich. Man kann hier so
einen Autopfad eintragen, aber da ist mir
00:10:19.270 --> 00:10:22.218
das halt zum ersten Mal so richtig
aufgefallen. Das war jetzt vor ein paar
00:10:22.218 --> 00:10:25.942
Jahren. Ich weiß gar nicht, wann das genau
war. Es gab so einen ähnlichen Fall
00:10:25.942 --> 00:10:30.041
nochmal: mit vim, dem Editor, den ich
immer benutze. Da kann man nämlich so
00:10:30.041 --> 00:10:33.882
Sachen machen wie in einem Kommentar in
der zu editierenden Datei in den ersten
00:10:33.882 --> 00:10:37.028
drei Zeilen oder in den letzten drei
Zeilen kann man so ein paar Konfig-
00:10:37.028 --> 00:10:41.870
Settings ändern. Das ist gedacht, um zu
sagen: "Ich benutz' hier in Tabstop von 4 oder
00:10:41.870 --> 00:10:46.160
so." Aber der Parser dafür hat ein
Sicherheitsproblem gehabt, und damit war
00:10:46.160 --> 00:10:50.512
es dann möglich, sozusagen eine Datei zu
erzeugen, die ein Programm ausgeführt hat,
00:10:50.512 --> 00:10:55.564
wenn sie in vim geöffnet wurde, was
natürlich nicht gewollt war. Aber es ist
00:10:55.564 --> 00:10:59.847
dasselbe Problem in grün. Und ich glaube,
das Problem kann man ein bisschen
00:10:59.847 --> 00:11:03.135
verallgemeinern, nachdem ich gerade gegen
Verallgemeinern gewettert habe, aber in
00:11:03.135 --> 00:11:06.535
der Betrachtung ist Verallgemeinern ja
gut, in der Software eher schlecht. Ich
00:11:06.535 --> 00:11:10.777
will das mal ein Beispiel illustrieren.
Nehmen wir an, wir haben eine CSV-Datei
00:11:10.777 --> 00:11:16.194
mit irgendwie Trouble-Tickets. Feld 4 ist
das, an dem wir jetzt Interesse haben.
00:11:16.194 --> 00:11:21.511
Nehmen wir an, die sieht so aus. CSV halt.
So, und jetzt möchte ich da gern die Summe
00:11:21.511 --> 00:11:26.285
der vierten Felder haben. Dann mache ich
als erstes mal cut, wir sind halt unter
00:11:26.285 --> 00:11:31.012
Unix. Der filtert es hier raus, die
erste Zeile muss noch weg, also mach ich
00:11:31.012 --> 00:11:34.193
hier noch einen tail. Dann ist die
erste Zeile weg, jetzt muss ich noch eine
00:11:34.193 --> 00:11:37.746
Summe bilden. Da gibt es auch ein Programm
für: paste. Wie man das halt macht unter
00:11:37.746 --> 00:11:43.442
Unix. Und dann muss ich das ausrechnen.
So! Aber was ist denn, wenn da jetzt nicht
00:11:43.442 --> 00:11:49.381
1 stand, sondern fred? Dann können wir
feststellen: cut hat damit kein Problem,
00:11:49.381 --> 00:11:54.442
tail hat damit kein Problem, paste hat
damit kein Problem, aber bc fällt auf die
00:11:54.442 --> 00:12:01.973
Fresse. So, das heißt, schlimmer noch: bc
ist programmierbar. Da könnte jetzt zum
00:12:01.973 --> 00:12:05.214
Beispiel die Ackermann-Funktion stehen und
dann steht der Rechner für eine Stunde,
00:12:05.214 --> 00:12:09.772
während er versucht, irgendeine Rekursion
aufzulösen. Und ich glaube, das ist
00:12:09.772 --> 00:12:14.823
sinnvoll, hier ein Konzept einzuführen und
zu sagen: cut, tail und paste sind
00:12:14.823 --> 00:12:18.817
harmlos, bc nicht. Das war so einer der
Gedanken, wo ich dachte: "Okay, da kann
00:12:18.817 --> 00:12:22.152
man eigentlich mal ein Vortrag drüber
machen." Allerdings ist es nicht
00:12:22.152 --> 00:12:27.235
hinreichend. Es gibt verschiedene Arten
von Harmlosigkeit. Aber ich glaube, die
00:12:27.235 --> 00:12:31.405
Unterscheidung ist schon mal hilfreich.
Ja, sagen wir mal, versuchen wir es einmal
00:12:31.405 --> 00:12:35.204
zu formulieren: Software ist harmlos, wenn
unerwartete Eingaben kein unerwartetes
00:12:35.204 --> 00:12:38.868
Verhalten oder unerwartete Arten von
Ausgabe erzeugen. Zum Beispiel, so eine
00:12:38.868 --> 00:12:43.166
SHA-Checksumme ist immer harmlos:
Egal, was ich dafür Daten rein tue, die
00:12:43.166 --> 00:12:47.742
Ausgabe hat ein bekanntes Format.
Oder word count (wc) ist auch so ein Ding.
00:12:47.742 --> 00:12:52.104
Jetzt könnte man sagen: "Okay, nimm
doch noch awk!" Und in awk habe ich zum
00:12:52.104 --> 00:12:55.955
Beispiel kein Problem, wenn da jetzt fred
steht statt 4 und der Interpreter
00:12:55.955 --> 00:13:00.541
interpretiert ja auch nicht Funktionen.
Das sieht besser aus, aber es ist auch
00:13:00.541 --> 00:13:05.397
harmlos, und es stellt sich heraus: awk
ist eine andere Art von nicht harmlos,
00:13:05.397 --> 00:13:09.385
denn man kann im Code im Dateisystem
rumschreiben. Da muss ich jetzt nicht auf
00:13:09.385 --> 00:13:13.548
die Eingabe achten. Aber ich muss auf die
andere Eingabe achten, nämlich den Code,
00:13:13.548 --> 00:13:17.275
den ich auf der Kommandozeile übergebe.
Und da kann man eigentlich auch sagen,
00:13:17.275 --> 00:13:21.812
dass man die Unterscheidung haben möchte.
Das ist in der Industrie übrigens ein
00:13:21.812 --> 00:13:25.862
großes Problem: Die Spieleindustrie ist
dazu übergegangen, in großem Stil
00:13:25.862 --> 00:13:30.856
irgendwelche Interpreter in ihre Spiele
einzubauen, um die Business-Logik, also
00:13:30.856 --> 00:13:36.820
nicht die AI, sondern so kleine Skripte in
einer Skriptsprache machen zu können und
00:13:36.820 --> 00:13:41.132
einer der beliebtesten Skript-Interpreter
dafür ist Lua. Und Lua wird vor allem
00:13:41.132 --> 00:13:45.091
deswegen genommen, weil der halt nix kann,
was man nicht freischaltet. Also der kann
00:13:45.091 --> 00:13:48.926
nicht Datei öffnen, kann keine Sockets
aufmachen. Das kann man alles nachreichen,
00:13:48.926 --> 00:13:53.190
und dann hat man natürlich wieder ein
Problem. Aber das ist ein reales Problem.
00:13:53.190 --> 00:13:57.149
Viele Open-Source-Leute denken da nicht
drüber nach, weil sie sich denken: "Ach,
00:13:57.149 --> 00:14:00.358
ich liefer das aus und der Rest ist ja
nicht mehr mein Problem." Aber ich finde,
00:14:00.358 --> 00:14:03.335
da müssen wir mal generell drüber
nachdenken, und zwar am besten vor dem
00:14:03.335 --> 00:14:06.771
Ausliefern, am besten schon beim
Programmieren. Also das ist eine andere
00:14:06.771 --> 00:14:11.226
Art von Harmlosigkeit. Vorher war die
Harmlosigkeit: "Kann eine böse Eingabe böse
00:14:11.226 --> 00:14:15.014
Ergebnisse erzielen?" Und jetzt ist: "Kann
das Programm selbst böse Dinge machen?"
00:14:15.014 --> 00:14:19.322
Und das ist eigentlich eine sehr moderne
Überlegung, weil wir heutzutage viel mit
00:14:19.322 --> 00:14:23.874
Sandboxing arbeiten. Da geht es genau
darum, zu verhindern, dass ein Programm
00:14:23.874 --> 00:14:28.024
versehentlich oder absichtlich böse Dinge
tut. Und da gibt's wieder auch verschiedene
00:14:28.024 --> 00:14:32.605
Sachen, die ein Programm anstellen kann.
bc konnte Rechenzeit verbraten. awk kann
00:14:32.605 --> 00:14:37.095
im Dateisystem lesen und schreiben, und
das geht natürlich weiter. Kommen wir
00:14:37.095 --> 00:14:41.740
zurück zum GNU Manifesto: GNU awk ist eine
spezielle Version von awk und die kann
00:14:41.740 --> 00:14:45.652
Sockets aufmachen, völlig ohne Not. Das
heißt, wenn wir einfach awk benutzen und
00:14:45.652 --> 00:14:49.086
denken, ach awk kann im Dateisystem
schreiben, aber das hab ich read-only
00:14:49.086 --> 00:14:53.457
gemountet, da passiert schon nichts. Dann
ist aber GNU awk im Einsatz, ist es halt
00:14:53.457 --> 00:14:57.802
doch wieder nicht harmlos. Bash kann
übrigens auch Sockets aufmachen! Ich weiß
00:14:57.802 --> 00:15:02.788
nicht, wie viele Leute das wussten? Gut,
die Sache geht natürlich noch weiter: Nach
00:15:02.788 --> 00:15:06.446
awk kam Perl. Das ist noch viel schlimmer
und Perl kann eval(), das ist so das
00:15:06.446 --> 00:15:11.425
schlimmste Übel, was man haben kann in einer
Programmiersprache aus meiner Sicht. Ein
00:15:11.425 --> 00:15:15.985
bisschen näher am Endkunden kann man das
auch an Browsern betrachten. Also gucken
00:15:15.985 --> 00:15:20.523
wir uns zum Beispiel mal Netscape an:
Netscape hat auch mehrfach die Wahl gehabt
00:15:20.523 --> 00:15:24.977
zwischen nützlich und harmlos und hat
immer nützlich gewählt. Es ging dann los
00:15:24.977 --> 00:15:29.442
mit den Plugins. Weiß nicht, wer sich hier
noch an das Flash-Plugin erinnert, oder
00:15:29.442 --> 00:15:33.755
vorher hatten wir alle den RealPlayer und
das [Adobe] Acrobat-Plugin gab es auch
00:15:33.755 --> 00:15:37.641
mal - und das war alles scheiße, weil
diese Plugins Native Code waren: die
00:15:37.641 --> 00:15:41.829
konnten alles tun, was das Betriebssystem
ihnen erlaubt. Das heißt, das war zwar
00:15:41.829 --> 00:15:45.635
sehr nützlich, aber es war eben auch sehr
gefährlich. Und das war eine bewusste
00:15:45.635 --> 00:15:49.579
Entscheidung von den Browsern, das
zuzulassen. Das eigentliche Ziel von
00:15:49.579 --> 00:15:54.202
diesem Vortrag ist, den Programmierern
unter euch so ein bisschen das Bewusstsein
00:15:54.202 --> 00:15:58.933
dafür zu geben, dass man nicht einfach
eine Plugin-Schnittstelle einbaut, die
00:15:58.933 --> 00:16:04.564
alles kann. Die nächste Iteration war: Wir
machen einfach alles in JavaScript. Das
00:16:04.564 --> 00:16:09.562
war, sah erst mal besser aus, aber dieser
JavaScript lief dann auch mit genügend
00:16:09.562 --> 00:16:13.861
Rechten, um im System Mist anzustellen und
zumindest im Browser Mist anzustellen. Da
00:16:13.861 --> 00:16:17.610
stellt sich heraus: Die Leute haben ihre
wichtigen Daten heutzutage im Browser,
00:16:17.610 --> 00:16:21.064
weil sie Onlinebanking machen. Und das
reicht, um richtig doll Schaden
00:16:21.064 --> 00:16:25.609
anzustellen. Da musste auch nachkorrigiert
werden. Chrome limitiert jetzt noch weiter
00:16:25.609 --> 00:16:29.383
aus Sicherheitsgründen, um den Adblocker
kaputtmachen zu können. Das ist eigentlich
00:16:29.383 --> 00:16:32.601
immer dieselbe Falle, in die wir hier
reinlaufen. Ich weiß nicht, wer hier
00:16:32.601 --> 00:16:37.285
Windows benutzt? Unter Windows gibt es ein
Tool, das von Mark Russinovich - der hat
00:16:37.285 --> 00:16:41.300
sich inzwischen kaufen lassen von
Microsoft, ist jetzt also ein offizielles
00:16:41.300 --> 00:16:44.680
Microsoft-Tool. Und die einzige Funktion
von dem Tool ist, die verschiedenen
00:16:44.680 --> 00:16:48.013
Plugins zu listen, die im System
eingetragen sind. Und ich habe hier mal
00:16:48.013 --> 00:16:52.285
ein relativ sauberes System genommen. Es
geht jetzt nicht um das hier unten oder
00:16:52.285 --> 00:16:56.549
die Größe von dem Scrollbalken, sondern
einfach, wie viele Tabs es oben gibt: Das
00:16:56.549 --> 00:17:00.745
sind alles Möglichkeiten, wie sich Plugins
im System einnisten können, und das hat
00:17:00.745 --> 00:17:04.445
einfach niemand mehr im Blick, weil
einfach immer in die falsche Richtung
00:17:04.445 --> 00:17:08.798
entschieden wurde. Also, das ist, glaube
ich, ein Kernproblem. Es gab noch eine
00:17:08.798 --> 00:17:13.857
dritte Herleitung: Mein Security-Alltag
besteht darin, dass sich Firmen gehe und
00:17:13.857 --> 00:17:17.926
zeigen mir ihren Quellcode und dann suche
ich nach Bugs. Und dann sage ich denen,
00:17:17.926 --> 00:17:21.920
welche Bugs ich gefunden habe. Und da
gibts dann halt gelegentlich so Fälle, wo
00:17:21.920 --> 00:17:25.808
man mitkriegt: Da gibt's ganz viele Bugs,
ja gar nicht mal nur die, die ich finde,
00:17:25.808 --> 00:17:30.035
sondern die haben schon eine eigene
Datenbank, einen Bugtracker, und da sind
00:17:30.035 --> 00:17:34.955
schon siebenstellig Bugs drin. Ja, sowas
kommt vor. Und weil das so ein Problem
00:17:34.955 --> 00:17:39.361
ist, dass wir so viele Bugs haben, gibt's
jetzt Gegenstrategien von den Entwicklern,
00:17:39.361 --> 00:17:42.746
die dann anfangen zu sagen: "Okay, wenn
der Bug nicht wichtig ist, dann kann ich
00:17:42.746 --> 00:17:46.830
ihn ja später fixen." Und das heißt in der
Realität: nie. Der liegt dann halt rum.
00:17:46.830 --> 00:17:52.134
Ich versuche seit einer Weile, den Begriff
Bug-Welle dafür zu etablieren, die man
00:17:52.134 --> 00:17:58.087
vor sich herschiebt als großer Dampfer.
Aber Bugtracker sind in der Realität da
00:17:58.087 --> 00:18:03.812
draußen häufig riesige Daten-Endlager: Ich
habe zum Beispiel neulich einen Bug
00:18:03.812 --> 00:18:08.146
bei Firefox gemeldet und habe die ID
1.590.000 gekriegt. Das ist ja schon
00:18:08.146 --> 00:18:11.876
ein schlechtes Zeichen, eigentlich. Aber
es ist ein gutes Zeichen, weil der
00:18:11.876 --> 00:18:16.007
Bugtracker offen ist. Bei Microsoft kann
man das gar nicht sehen, wie viel Bugs die
00:18:16.007 --> 00:18:19.501
haben. Das ist jetzt hier nur als
Illustration gemeint. Mozilla ist nicht
00:18:19.501 --> 00:18:23.170
besonders scheiße. Mozilla hat nur einen
offenen Tracker, an dem ich das schön
00:18:23.170 --> 00:18:27.217
etablieren kann. Was ich jetzt noch zeigen
wollte - ich hab noch mal geguckt: "Was ist
00:18:27.217 --> 00:18:31.017
denn der erste Bug, den ich da gefiled
habe?" Der hatte noch eine sechsstellige
00:18:31.017 --> 00:18:37.953
ID. Das war 2003. Wenn man sich den
Verlauf anguckt, der Bugnummern, dann
00:18:37.953 --> 00:18:43.047
stellt man fest: Das wächst exponentiell.
Und es ist nicht so, dass die Bugs dann
00:18:43.047 --> 00:18:48.431
irgendwie irgendwann weggehen von
irgendwann. Ich habe zwei große Ereignisse
00:18:48.431 --> 00:18:52.235
beobachtet, bei denen Bugs geschlossen
werden: Das ist, wenn es ein neues Release
00:18:52.235 --> 00:18:55.851
gibt, und da schmeißt man die alte
JavaScript-Engine raus und macht eine neue
00:18:55.851 --> 00:18:59.700
rein. Dann schließt man alle Bugs von der
alten Engine. Das sieht dann so aus, als
00:18:59.700 --> 00:19:03.568
wenn man was geschafft hat. Und der
andere Weg ist dieser hier: Ich weiß nicht,
00:19:03.568 --> 00:19:06.848
ob man das hinten lesen kann? Mozilla hat
einfach einen Bug von mir geschlossen. Da
00:19:06.848 --> 00:19:10.034
steht drin: "This bug has been
automatically resolved after a period of
00:19:10.034 --> 00:19:14.008
inactivity". Die war jetzt
nicht von mir, die Inactivity. Ich hab den Bug gefiled,
00:19:14.008 --> 00:19:17.750
und bei Mozilla hat sich keiner drum
gekümmert. Und dann haben die den halt
00:19:17.750 --> 00:19:21.355
automatisch geschlossen, weil die
Statistik so schlecht aussah. Das ist ein
00:19:21.355 --> 00:19:24.378
Riesenproblem, nicht nur bei Mozilla. Wie
gesagt, das ist hier nur der
00:19:24.378 --> 00:19:28.262
Blitzableiter, den ich zeigen kann, weil
es alles öffentlich ist bei denen. Aber
00:19:28.262 --> 00:19:32.349
das führt zu so einer Kaskade aus
Verhalten und Gegenverhalten. Zum Beispiel
00:19:32.349 --> 00:19:36.089
sieht man dann: unwichtige Bugs werden
halt gar nicht gefixt. Und dann schreiben
00:19:36.089 --> 00:19:39.461
die Leute halt "wichtig" an ihre Bugs,
wenn sie wollen, dass die gefixt werden.
00:19:39.461 --> 00:19:42.780
Und da haben die Leute gesagt: "Okay,
die wichtigen Bugs bleiben dann
00:19:42.780 --> 00:19:46.849
auch liegen, weil da gibt's zu viele
von." Und dann schreiben die Leute
00:19:46.849 --> 00:19:51.472
"Security" an ihre Bugs ran, und dann
haben wir jetzt eine Welle von Security-
00:19:51.472 --> 00:19:56.008
Bugs, und da wird dann verhandelt: "Ist das
denn wirklich ein Problem?" Und da kommen
00:19:56.008 --> 00:20:01.232
dann so Ausreden, wie: "Ist ja nur ein
Crash." Und der Punkt daran ist, dass es
00:20:01.232 --> 00:20:07.589
hier eine unheilige Allianz gibt mit einem
anderen Trend, nämlich, dass Firmen
00:20:07.589 --> 00:20:11.476
einfach sehen: sie haben so viele Bugs
offen, dass es gar nicht das Ziel ist, sie
00:20:11.476 --> 00:20:15.295
alle loszuwerden. Es gibt einfach zu
viele, das ist unrealistisch. Stattdessen
00:20:15.295 --> 00:20:19.598
führt man Metriken ein, wie
dass man Fuzzing macht. Fuzzing ist
00:20:19.598 --> 00:20:23.897
eigentlich keine doofe Idee, aber es ist
eben nicht: "alle Bugs finden", sondern es
00:20:23.897 --> 00:20:28.090
ist nur der erste Schritt auf einer langen
Straße. Aber es ist halt eine schöne
00:20:28.090 --> 00:20:33.011
Metrik, die da rausfällt. Wir haben so und
so viel Fuzz-Testcases gemacht, und jetzt...
00:20:33.011 --> 00:20:37.402
Sind wir jetzt besser oder schlechter als
vorher? Ist alles schwer zu sagen.
00:20:37.402 --> 00:20:41.769
Dann gibt es Bug Bounties, was ich
persönlich für Bullshit halte. Das macht
00:20:41.769 --> 00:20:46.975
man, damit die PR-Abteilungen zeigen kann:
"Guck mal, so viel wert sind Bugs bei uns,
00:20:46.975 --> 00:20:51.635
weil wir so wenig Bugs haben." Das ist die
Idee. Und der Rest der Industrie hat
00:20:51.635 --> 00:20:55.373
einfach Mitigations gemacht. Da haben Sie
dann gesagt: "Okay, wir schließen die Bugs
00:20:55.373 --> 00:20:58.367
nicht mehr, wir machen das Exploiten
schwieriger." Und das funktioniert. Ich
00:20:58.367 --> 00:21:01.752
bin da immer dagegen gewesen. Ich musste
also jetzt meinen Hut fressen, sozusagen.
00:21:01.752 --> 00:21:05.930
Das funktioniert. Aber es hat halt
Nebeneffekte. Ich weiß nicht, ob ich Zeit
00:21:05.930 --> 00:21:09.778
habe für Anekdoten. Ich bin nämlich
zeitlich sehr knapp dran. Aber ich hab mal
00:21:09.778 --> 00:21:13.974
den Typ getroffen, der die Internet-
Explorer-Bugs verwaltet, die reinkommen,
00:21:13.974 --> 00:21:18.438
und ich habe den getroffen, weil ich 50
Bugs gefiled habe. Und er hat gesagt "35
00:21:18.438 --> 00:21:20.345
kenne ich schon".
Publikum lacht
00:21:20.345 --> 00:21:23.400
Und da hab ich gesagt: "Wie jetzt?" Der
00:21:23.400 --> 00:21:28.686
Typ sah aus wie Gollum in so einer Cave.
Der war irgendwie 30 und sah aus wie Ende 60.
00:21:28.686 --> 00:21:33.658
Gelächter Und der meinte: "Es kommen so viele
Bugs hier rein, wir kommen gar nicht dazu,
00:21:33.658 --> 00:21:37.336
irgendwelche zu schließen, wir verwalten
die nur noch." Das war der Stand
00:21:37.336 --> 00:21:41.931
damals. Das ist inzwischen besser
geworden. Also Microsoft. Und wie gesagt,
00:21:41.931 --> 00:21:47.848
das sind hier Beispiele, das ist in
anderen Firmen ähnlich. Man verwaltet die
00:21:47.848 --> 00:21:51.779
Bugs, und man schließt sie nicht mehr, und
memgc ist eine Sache, da habe ich lange
00:21:51.779 --> 00:21:55.288
Jahre gar nicht drüber reden dürfen. Aber
inzwischen haben sie das selbst
00:21:55.288 --> 00:21:58.910
veröffentlicht. Deswegen darf ich das
jetzt doch erzählen. Da haben sie halt
00:21:58.910 --> 00:22:03.159
festgestellt Wir haben lauter Memory
Corruption Bugs, weil wir immer die Sachen
00:22:03.159 --> 00:22:07.913
vom Heap free()n und dann aber noch
benutzen. Da haben Sie jetzt einen Hack
00:22:07.913 --> 00:22:12.536
gebaut, der die Sachen dann halt nicht
free()t, sondern in eine Liste tut. Und
00:22:12.536 --> 00:22:17.253
dann läuft ja über den Stack und guckt
nach Pointern, die in die Liste zeigen und
00:22:17.253 --> 00:22:21.690
gibt die dann nicht frei. Das ist ein
furchtbarer Hack. Wär' mir ja zu peinlich
00:22:21.690 --> 00:22:26.237
gewesen, das irgendwo zu erwähnen. Aber
Microsoft macht jetzt PR damit, wie geil
00:22:26.237 --> 00:22:30.208
memgc ist. Und die Chrome-Leute haben
sich das angesehen haben und gesagt:
00:22:30.208 --> 00:22:33.999
"Boah, das ist ja geil."
Publikum lacht
00:22:33.999 --> 00:22:36.695
Das ist der Stand, wie die Industrie
00:22:36.695 --> 00:22:41.009
funktioniert. Das Problem ist jetzt aber,
dass Bugs nur noch mit Exploit als
00:22:41.009 --> 00:22:45.459
Security-Problem anerkannt werden. Also
das ist nicht branchenübergreifend, aber
00:22:45.459 --> 00:22:49.214
es ist bei vielen inzwischen so: Wenn man
keinen Exploit liefert, wird es nicht
00:22:49.214 --> 00:22:52.446
anerkannt. Aber wir haben ja vorhin
gesehen, dass überhaupt nur noch
00:22:52.446 --> 00:22:56.310
anerkannte Security-Bugs gefixt werden.
Das heißt, Bugs liegen einfach herum, weil
00:22:56.310 --> 00:23:00.526
der Nachweis nicht erbracht werden konnte.
Und wenn das Ausnutzen von einem Bug durch
00:23:00.526 --> 00:23:04.246
die Mitigations schwieriger wird, heißt
das eben, dass immer mehr tatsächliche
00:23:04.246 --> 00:23:07.796
Sicherheitsprobleme rumliegen, weil
niemand Bock hat, den Nachweis zu
00:23:07.796 --> 00:23:12.318
erbringen, dass es ein Problem war. Das
heißt nicht, dass keiner von den Bugs
00:23:12.318 --> 00:23:16.240
jemals geschlossen wird. Denn es stellt
sich heraus: Die Entwickler haben so etwas
00:23:16.240 --> 00:23:20.475
wie einen Anspruch an ihren Code. Keiner
möchte der Typ sein, der die Brücke in
00:23:20.475 --> 00:23:24.298
Genua gebaut hat. Das heißt, die Leute
laufen schon rum und schließen Bugs. Aber
00:23:24.298 --> 00:23:27.676
sie möchten halt nicht gezwungen werden
dazu. Und sie möchten auch nicht
00:23:27.676 --> 00:23:31.460
anerkennen, dass es ein Problem war. Und
das hat so eine Kaskade an Problemen in
00:23:31.460 --> 00:23:36.410
der Realität. Aber ich schließe daraus:
Erst mal reaktiv auf das Problem mit den
00:23:36.410 --> 00:23:41.173
Bugs und der Softwarequalität zuzugehen,
hilft eigentlich nicht. Ich sage das schon
00:23:41.173 --> 00:23:45.020
länger über Viren und Würmer und die
Antiviren, die ich immer als Schlangenöl
00:23:45.020 --> 00:23:48.800
bezeichne. Ich glaube, dass das bei Bugs
auch so ist: Viel zu viel Software wird
00:23:48.800 --> 00:23:53.213
einfach entwickelt, und man denkt sich:
"Ach naja, dann können wir das mal ausliefern,
00:23:53.213 --> 00:23:57.578
und der Kunde testet das dann. Und dann
melden die schon die Bugs und die fixen
00:23:57.578 --> 00:24:03.977
wir dann halt." Es gibt so inzwischen das
geflügelte Wort: Man liefert aus, wenn der
00:24:03.977 --> 00:24:10.106
Updater funktioniert. Und da muss man ja
irgendwie mit umgehen als Industrie. Ich
00:24:10.106 --> 00:24:13.625
versuche hier als Zielgruppe jetzt die
Entwickler. Was machen wir denn jetzt? Das
00:24:13.625 --> 00:24:17.247
ist jetzt so die Frage. Und da gibt es
natürlich verschiedene Ideen: Der FDP-
00:24:17.247 --> 00:24:21.130
Ansatz ist meines Erachtens gescheitert.
Der Markt hat ja gar nichts geregelt. Die
00:24:21.130 --> 00:24:24.965
Leute kaufen immer noch alle irgendwie
Windows und macOS. Das funktioniert,
00:24:24.965 --> 00:24:28.860
glaube ich, nicht. Dann kann man
versuchen, an die Moral zu appellieren.
00:24:28.860 --> 00:24:33.035
Freiwillige Selbstkontrolle? Das
funktioniert auch nicht aus meiner Sicht.
00:24:33.035 --> 00:24:37.879
Dann gibt es den BSI-Ansatz: "Wir tun einfach
ein paar Lagen Schlangenöl drüber..." Das
00:24:37.879 --> 00:24:42.818
funktioniert leider auch nicht. Und es
gibt den Twitter-Ansatz: Ausgrenzung
00:24:42.818 --> 00:24:48.100
und mit Dingen drohen. Heugabelmobs. Das
hat in meiner Beobachtung eher zu
00:24:48.100 --> 00:24:52.500
Abandonware geführt, weil die Leute halt
weggerannt sind, und gesagt haben:
00:24:52.500 --> 00:24:56.206
"Das ist mir doch egal. Das ist nicht mehr
meine Software." Es gibt auch einen
00:24:56.206 --> 00:24:59.868
Hybridansatz, den die katholische Kirche
seit vielen Jahren erfolgreich fährt.
00:24:59.868 --> 00:25:03.716
Vielleicht ist das die Lösung. Dass man
sagt: "Nicht der Markt, aber Sankt Peter
00:25:03.716 --> 00:25:08.630
regelt das." Und an Moral appellieren
funktioniert so ein bisschen. Das müssen
00:25:08.630 --> 00:25:13.261
wir vielleicht ausbauen. Und dann dachte
ich mir: "Was machen wir jetzt konkret?" Ich
00:25:13.261 --> 00:25:16.930
habe als erstes gedacht: "Wir müssen
vielleicht gucken, ob wir die explorative
00:25:16.930 --> 00:25:19.907
Softwareentwicklung von der
zielorientierten Softwareentwicklung
00:25:19.907 --> 00:25:23.917
trennen." Dass wir sagen, es ist gut und
richtig, dass die Leute explorativ lernen.
00:25:23.917 --> 00:25:27.947
Aber das ist dann nicht das Produkt, was
du shippst. Da müssen wir irgendwie
00:25:27.947 --> 00:25:31.971
hinkommen. Und ich appelliere seit Jahren
an die Firmen und sage: "Gebt den Leuten
00:25:31.971 --> 00:25:35.440
Zeit, dass sie ein bisschen rumspielen und
Sachen lernen können!" Denn sonst lernen
00:25:35.440 --> 00:25:39.425
sie das während der Produktentwicklung und
dann wird das Produkt halt scheiße. Aber
00:25:39.425 --> 00:25:44.229
da kann ich so lange reden, bis ich blau
anlaufe. Der Effekt ist bisher nicht
00:25:44.229 --> 00:25:48.829
vorzeigbar. Ich finde, man kann das gut
auf den Punkt bringen, wenn man sagt:
00:25:48.829 --> 00:25:52.582
"Sei innovativ damit, was du tust, und
nicht, wie du es tust." Eine Firma soll ja
00:25:52.582 --> 00:25:57.265
innovativ sein, soll Dinge probieren, neue
Produkte machen, aber dann nicht
00:25:57.265 --> 00:26:02.796
irgendeine Experimental-Datenbank-Tech
anwenden, die dann irgendwie mit den Daten
00:26:02.796 --> 00:26:08.344
verloren geht, weil - war noch nicht
fertig. Ich glaube, es gibt da nicht nur
00:26:08.344 --> 00:26:13.337
eine Ursache, sondern es gibt mehrere
Komponenten und die muss man auch getrennt
00:26:13.337 --> 00:26:16.676
betrachten. Die erste ist Unwissenheit.
"Ich weiß einfach nicht, dass der Code
00:26:16.676 --> 00:26:19.707
scheiße war, den ich da importiert habe."
Oder "Ich wusste nicht, wie man es besser
00:26:19.707 --> 00:26:23.220
macht, deswegen habe ich es halt nicht gut
gemacht." Und dann gibt's, was ich mal
00:26:23.220 --> 00:26:26.838
absichtliche Unwissenheit nenne: "Wir
haben keine guten Leute gefunden." Das
00:26:26.838 --> 00:26:30.901
halte ich für eine Ausrede. Wer möchte und
wer gut zahlt, findet auch gute Leute.
00:26:30.901 --> 00:26:34.758
Solange das Projekt irgendwie so ein
bisschen was an sich hat, was man
00:26:34.758 --> 00:26:38.616
vielleicht mal ausprobieren möchte. Das
halte ich für eine Ausrede. Ich glaube,
00:26:38.616 --> 00:26:42.095
das sagen Leute, die sagen: "Ach, es ging
halt nicht anders, wir haben schlechte
00:26:42.095 --> 00:26:46.015
Leute. Dann wird das Produkt halt nicht so
gut. Es macht ja nix. Also war nicht meine
00:26:46.015 --> 00:26:49.071
Schuld." Halte ich für eine
Schutzbehauptung. Und dann gibt es
00:26:49.071 --> 00:26:53.416
natürlich Inkompetenz. Also so richtig.
"Ach, das ging gar nicht anders." - ich habe
00:26:53.416 --> 00:26:57.395
neulich so einen Kunden gehabt. Das
sieht häufig nicht aus wie Ausreden,
00:26:57.395 --> 00:27:01.075
sondern wie Best Practices. Aber ich halte
es für Ausreden. Ich habe neulich so einen
00:27:01.075 --> 00:27:03.522
Kunden gehabt, die meinen jetzt: "Wir
machen jetzt eine Plattform für
00:27:03.522 --> 00:27:06.250
Energiehandel", also kritische
Infrastruktur, würde man eigentlich sagen.
00:27:06.250 --> 00:27:09.796
Die haben gesagt: "Wir machen das in der
Cloud, weil selber hosten können wir gar nicht."
00:27:09.796 --> 00:27:13.000
- "Ja, warum denn nicht?"
- "Das ist so teuer."
00:27:13.897 --> 00:27:17.249
Publikum lacht
00:27:17.249 --> 00:27:22.275
Verstehe ich nicht. Ich glaube, wir haben
da so eine Kaskade aus Ausreden, die vor
00:27:22.275 --> 00:27:26.830
uns hergeschoben werden. Der Ansatz, den
ich jetzt gehen möchte, ist, dass ich
00:27:26.830 --> 00:27:29.650
sage, wir versuchen vielleicht so eine Art
Legacy-Faktor zu definieren, den man
00:27:29.650 --> 00:27:33.349
an die Software dran schreibt. Und da
geht es nicht darum: "Wie schlecht ist die
00:27:33.349 --> 00:27:37.155
Software?", sondern "Wie negativ
beeinträchtigt wird meine Software, wenn
00:27:37.155 --> 00:27:41.157
ich das als Dependency reinnehme?". Also
wenn ich jetzt irgendeine Library
00:27:41.157 --> 00:27:46.006
reinziehe, wieviel negative Auswirkungen
hat das? Das Problem ist aber: Wenn wir
00:27:46.006 --> 00:27:49.877
das als Metrik machen und die wird
irgendeine Art von Erfolg im Markt haben,
00:27:49.877 --> 00:27:53.429
dass die Leute dann natürlich bescheißen
werden und werden nach der Metrik
00:27:53.429 --> 00:27:56.744
optimieren und nicht nach dem
tatsächlichen Ziel der Metrik. Daher ist
00:27:56.744 --> 00:28:00.948
das so ein bisschen schwierig, aber es
gibt ein Vorbild, was so ein bisschen
00:28:00.948 --> 00:28:05.771
funktioniert, nämlich das CVSS - das das
Common Vulnerability Scoring System. Das
00:28:05.771 --> 00:28:10.095
wird angewendet, um die Problematik
von Bugs zu messen. Da haben sich also
00:28:10.095 --> 00:28:14.460
Leute zusammengetan und versucht, eine
Metrik zu definieren. Und die funktioniert
00:28:14.460 --> 00:28:19.729
in der Industrie gut, die wird angenommen.
Die Leute lieben das. Das funktioniert
00:28:19.729 --> 00:28:24.462
grob so, wie eine historische
Risikobewertung. Man guckt halt so, wie
00:28:24.462 --> 00:28:28.774
wahrscheinlich ist, dass das passiert,
dass das jemand ausnutzt. Da gibt's dann
00:28:28.774 --> 00:28:33.027
Kriterien wie: Ist das technisch
aufwendig? Kommt man da ran, wenn man
00:28:33.027 --> 00:28:38.276
lokal einen Account hat oder auch über
Netzwerk? Und was macht man denn kaputt,
00:28:38.276 --> 00:28:42.951
wenn man das ausnutzt? Kann man dann Daten
löschen, oder kann man die verändern? Also
00:28:42.951 --> 00:28:46.781
diese Art von Sachen klickt man an, und
dann kommt ein Score raus. Das finde ich
00:28:46.781 --> 00:28:50.708
eigentlich eine gute Sache. Ich glaube,
wir brauchen so ein Risiko-Score - jetzt
00:28:50.708 --> 00:28:54.292
nicht für Bugs. Bei Bugs ist es, glaube
ich, einfacher zu machen, obwohl es auch
00:28:54.292 --> 00:28:58.676
schon viele Detail-Schwierigkeiten hat.
Aber eigentlich brauchen wir so eine Art
00:28:58.676 --> 00:29:03.695
Risiko-Score, entweder für das Management
oder für die Entwickler. Und das sind
00:29:03.695 --> 00:29:07.750
getrennte Probleme. Ich glaube, dass es
zielführender, sich an die Entwickler zu
00:29:07.750 --> 00:29:10.944
halten. Denn ich habe bisher noch fast nie
erlebt, dass Management gesagt hat: "Das
00:29:10.944 --> 00:29:14.235
muss jetzt besser werden. Und das war
nicht nur als PR gemeint." Sondern, aber
00:29:14.235 --> 00:29:18.170
Entwickler haben so eine Art Anspruch an
ihren Code. Und ich glaube, wenn man denen
00:29:18.170 --> 00:29:21.906
hilft zu erkennen, ob sie gerade einen
Fehler machen, können wir was stemmen.
00:29:21.906 --> 00:29:25.648
Dann habe ich mir gedacht: Welche
Dimensionen gibt's denn da? Das ist leider
00:29:25.648 --> 00:29:29.813
ein mehrdimensionales Problem. Hier ist
eine der Dimensionen, die ich mir überlegt
00:29:29.813 --> 00:29:33.962
habe: Sicherheitslöcher. Gut, klar. Wenn
der Code Sicherheitslöcher hat, ist das
00:29:33.962 --> 00:29:37.258
ein Problem. Aber das ist leider ein
offenes Forschungsfeld, wie man die
00:29:37.258 --> 00:29:40.789
Sicherheitslöcher finden soll. Und vor
allem dafür eine Metrik zu haben. Jetzt
00:29:40.789 --> 00:29:44.961
kann man sagen: "Wir haben jetzt 10 Bugs
gefunden, also war der Code wahrscheinlich
00:29:44.961 --> 00:29:49.101
unsicher." Und da ist was dran. Aber wir
wissen ja nicht, ob das alle 10 Bugs in
00:29:49.101 --> 00:29:53.353
dem Code waren. Ist der Rest von dem Code
vielleicht super, und das waren 10
00:29:53.353 --> 00:29:58.053
Ausrutscher? Das ist leider sehr schwer zu
messen. Daher eignet sich das, glaub ich,
00:29:58.053 --> 00:30:02.925
nicht als Metrik. In der Industrie gibt es
Versuche, mit Code-Smells und statischer
00:30:02.925 --> 00:30:07.068
Analyse zu arbeiten. Das ist eine Sache,
die im Moment sehr viele Firmen
00:30:07.068 --> 00:30:11.207
ausprobieren.Der Erfolg ist bisher eher
mäßig. Meine Beobachtung ist, dass man so
00:30:11.207 --> 00:30:15.768
ein Tool ausrollt, und der wirft dann zehn
Milliarden Warnungen. Und dann schaltet
00:30:15.768 --> 00:30:20.235
man so lange die Sensibilität von dem Tool
runter, bis die Menge verarbeitbar
00:30:20.235 --> 00:30:24.736
ist. Und dann verteilt man das an die
Entwickler, und die sagen: "Das sind aber
00:30:24.736 --> 00:30:28.717
alles False-Positives", und dann ist das
Projekt gescheitert. Dann lässt man das
00:30:28.717 --> 00:30:33.343
weiterlaufen, damit es nicht so aussieht,
als wäre es gescheitert. Aber dass
00:30:33.343 --> 00:30:38.565
tatsächlich was passiert, ist selten. Das
ist zwar eine wichtige Dimension, aber ich
00:30:38.565 --> 00:30:43.107
glaube, die können wir nicht ordentlich in
eine Metrik abbilden. Ich wüsste jedenfalls
00:30:43.107 --> 00:30:49.769
nicht, wie. Ich versuche das hier auch an
Beispielen zu illustrieren, vielleicht ein
00:30:49.769 --> 00:30:55.467
bisschen. Es gibt Extrema: es gibt einmal
qmail und sendmail. Das sind eigentlich
00:30:55.467 --> 00:30:59.760
ganz gute Illustrationsbeispiele: Das sind
beides MTAs, also Programme, die auf einem
00:30:59.760 --> 00:31:04.521
Server laufen und Mails weiter verschicken
oder annehmen.Und qmail ist gebaut worden
00:31:04.521 --> 00:31:08.482
mit dem Ziel, eine sichere Software zu
haben, da hat sich jemand erst das Design
00:31:08.482 --> 00:31:12.363
überlegt und dann die Software so gebaut.
Und sendmail ist erst geschrieben worden,
00:31:12.363 --> 00:31:18.015
dann kam jemand und meinte "Ja, vielleicht
brauchen wir auch ein Design", und das
00:31:18.015 --> 00:31:24.111
sieht man bis heute. qmail ist um 1993
veröffentlicht worden, ging bis Version
00:31:24.111 --> 00:31:29.850
1.0.3, und danach gab es nie wieder einen
Patch. Und ich setze das aber bis heute
00:31:29.850 --> 00:31:36.526
ein, weil es da nie wirklich Probleme gab,
das ist sozusagen fertige Software. Das
00:31:36.526 --> 00:31:42.156
ist so das eine Ende. Auf der anderen
Seite heißt es aber auch, dass neuere
00:31:42.156 --> 00:31:46.170
Features einfach nicht drin sind. Es ist
immer ein zweischneidiges Schwert. Das ist
00:31:46.170 --> 00:31:49.830
das Spektrum, auf dem wir uns bewegen: auf
der einen Seite so ein alter Legacy-
00:31:49.830 --> 00:31:53.224
Codehaufen, den keiner mehr wirklich
verwalten will, außer er wird bezahlt
00:31:53.224 --> 00:31:56.585
dafür. Und selbst unter den Leuten, die
bezahlt wurden, sind die meisten
00:31:56.585 --> 00:32:00.581
weggelaufen, übrigens. Das will einfach
niemand haben. Die zweite Dimension, über
00:32:00.581 --> 00:32:05.106
die man nachdenken kann, ist: "Gibt es
denn noch Wartung dafür?". Das kann man bei
00:32:05.106 --> 00:32:08.988
Open-Source-Produkten glücklicherweise
ganz gut erkennen. Bei kommerzieller
00:32:08.988 --> 00:32:12.573
Software ist das ein bisschen schwieriger,
weil da gibts dann vielleicht Patches und
00:32:12.573 --> 00:32:16.852
neue Versionen. Aber ob die auch
tatsächlich was ändern, ist halt nicht so
00:32:16.852 --> 00:32:21.549
klar. Oder wie viel sie ändern. Und das ist
auch nicht so klar, wie man das jetzt
00:32:21.549 --> 00:32:24.654
bewerten soll, denn wenn eine Software
keine Updates kriegt, muss es ja nicht
00:32:24.654 --> 00:32:28.779
heißen, dass sie scheiße ist. Kann ja auch
sein, dass die einfach fertig ist. Das ist
00:32:28.779 --> 00:32:34.307
zwar sehr, sehr selten, aber es gibt
Beispiele dafür: Zum Beispiel: TeX ist ein
00:32:34.307 --> 00:32:39.450
Satzsystem von Donald Knuth. Das hat er
geschrieben und ist jetzt fertig. Da gibt
00:32:39.450 --> 00:32:44.572
es zwar immer noch Patches, gelegentlich,
aber ganz selten. Und die ändern zwei Bits
00:32:44.572 --> 00:32:49.299
irgendwo. Das ist im Wesentlichen fertig.
Oder libjpeg habe ich hier als Beispiel
00:32:49.299 --> 00:32:52.794
genommen, das ist irgendwann geschrieben
worden von der Independent JPEG Group um
00:32:52.794 --> 00:32:56.071
Tom Lane und das hat eigentlich nie
irgendwelche Updates gebraucht. Das war
00:32:56.071 --> 00:32:59.467
einfach. Hat auch keine Sicherheitslücken
gehabt. Das ist deswegen jetzt nicht
00:32:59.467 --> 00:33:03.335
schlecht. Das heißt, dass es nicht so
einfach zu sagen: "Es gibt keine Patches
00:33:03.335 --> 00:33:08.721
mehr - also ist die Software scheiße." Die
Metrik ist also auch sehr schwierig. Wie
00:33:08.721 --> 00:33:13.595
machen wir das? Gute Frage. Gut, das hab
ich jetzt schon erzählt. Auf der anderen
00:33:13.595 --> 00:33:17.871
Seite ist es so: Wenn eine Software sehr
häufig geupdatet wird, ist das auch nicht
00:33:17.871 --> 00:33:22.411
unbedingt ein gutes Zeichen. Ich habe
einen Kunden, der hat eine Software von
00:33:22.411 --> 00:33:26.844
einem Drittanbieter, und der releast per
GitHub. Und da kommen dann pro Tag fünf
00:33:26.844 --> 00:33:31.971
Updates, und da steht aber jedes Mal
Release dran. Und gelegentlich brechen die
00:33:31.971 --> 00:33:37.346
was, gelegentlich nicht. Da hast du nie
irgendeinen Ansatzpunkt, um auch nur zu
00:33:37.346 --> 00:33:41.891
beurteilen, ob die Software jetzt gut ist
oder nicht. Weil in dem Moment, wo deine
00:33:41.891 --> 00:33:47.106
Untersuchung fertig ist, gibts schon
wieder 20 neue Versionen. Ja, das ist
00:33:47.106 --> 00:33:52.356
eigentlich auch nicht gut. Eine weitere
Dimension ist die Dependency-Hölle, die
00:33:52.356 --> 00:33:56.950
kennt ja fast jeder, der schon mal
Software entwickelt hat. Besonders krass
00:33:56.950 --> 00:34:01.703
ausgebildet bei JavaScript, die ein paar
Mal sehr öffentlich auf die Fresse
00:34:01.703 --> 00:34:05.389
geflogen sind, als zum Beispiel jemand ein
Modul zurückgerufen hat, von dem sich dann
00:34:05.389 --> 00:34:10.021
herausstellte, dass das irgendwie über
transitive Abhängigkeiten in fast allen
00:34:10.021 --> 00:34:15.049
Projekten irgendwie drin war. Das müsste
man dann transitiv anwenden. Wie gesagt:
00:34:15.049 --> 00:34:20.110
Wenn ich eine Software reinlade und die
hat 50 andere Dependencies, dann muss ich
00:34:20.110 --> 00:34:25.645
die Summe davon nehmen. Die Extrema dabei
wären auf der einen Seite so eine Cloud-
00:34:25.645 --> 00:34:29.835
Lock-in-Hölle, wo man die Abhängigkeiten
gar nicht sieht, sondern man hat halt
00:34:29.835 --> 00:34:34.685
irgendwie irgendeine Pipeline, aus der
fällt irgendwas raus, und der resolvt am
00:34:34.685 --> 00:34:39.107
besten die Abhängigkeiten noch
automatisiert während des Bauens und zieht
00:34:39.107 --> 00:34:43.660
sich irgendwas aus dem Internet - das ist
das eine Extrem. Und das andere Extrem ist
00:34:43.660 --> 00:34:48.532
wieder qmail. Der hat halt überhaupt keine
Abhängigkeiten, der benutzt die C-Library,
00:34:48.532 --> 00:34:54.215
das C-Runtime, das drauf ist und braucht
einen C-Compiler zum Bauen, und das war's.
00:34:54.215 --> 00:34:59.203
Da gibt es auch ein Spektrum, was sich ja
eigentlich für eine Metrik eignen würde.
00:34:59.203 --> 00:35:02.580
Aber wie gesagt, es gibt halt mehrere
Dimensionen. Wir kommen weiter. Nächste
00:35:02.580 --> 00:35:07.256
Dimension ist Codequalität, und das ist so
ein bisschen wie Security, aber ich möchte
00:35:07.256 --> 00:35:11.814
das verallgemeinern, und zwar unter
anderem deswegen, weil es eine relativ
00:35:11.814 --> 00:35:16.713
starke Korrelation zwischen vielen Bugs
und schlechter Security gibt. Alle
00:35:16.713 --> 00:35:21.634
Security-Probleme sind auch ein Bug. Wenn
jemand viele normale Bugs hat oder Bugs,
00:35:21.634 --> 00:35:25.555
von denen wir nicht wissen oder nicht
nachgewiesen haben, dass es ein
00:35:25.555 --> 00:35:30.453
Sicherheitsproblem ist, dann ist das im
Allgemeinen ein Zeichen dafür, dass da
00:35:30.453 --> 00:35:34.457
auch viele Sicherheitslücken drin
sein werden. Daher ist es wichtig als
00:35:34.457 --> 00:35:39.444
Metrik, selbst wenn es nicht um Sicherheit
geht. Wie gesagt, die Trends dazu sind
00:35:39.444 --> 00:35:44.786
statische Code-Analyse und Code-Smells.
Ich wäre noch dafür hundert Prozent
00:35:44.786 --> 00:35:50.341
Coverage beim Unit-Testing zu erwarten.
Aber das ist halt auch schwierig, weil da
00:35:50.341 --> 00:35:55.009
gibt es verschiedene Messverfahren. Zum
Beispiel: Was macht man, wenn mehr als ein
00:35:55.009 --> 00:35:59.622
Statement auf einer Zeile steht?
Was ist die Granularität des Testens?
00:35:59.622 --> 00:36:04.077
Ja, es ist alles nicht so einfach. Aber
wir sollten zumindest mal anfangen,
00:36:04.077 --> 00:36:07.868
darüber nachzudenken.Und mein Vorschlag
wäre, aus den eben erklärten Gründen, dass
00:36:07.868 --> 00:36:11.956
wir einfach gucken, welche bekannten Bugs
gibt's denn? Wie ist denn so...? Wie viele
00:36:11.956 --> 00:36:16.785
Bugs werden bekannt, pro sagen wir mal,
Jahr? Und daraus kann man extrapolieren.
00:36:16.785 --> 00:36:21.632
Die nächste Näherung wäre, dass man alle
Compiler-Warnungen anschaltet, was
00:36:21.632 --> 00:36:26.415
erschütternd wenige Software-Hersteller
machen in ihren internen Builds. Das ist
00:36:26.415 --> 00:36:30.549
wirklich erschreckend.Und was auch viele
Leute, die irgendwelche Pipelines in der
00:36:30.549 --> 00:36:34.335
Cloud benutzen, gar nicht mitkriegen, wie
viele Warnungen da eigentlich rausfliegen.
00:36:34.335 --> 00:36:38.224
Das ist eine der wichtigsten Metriken, die
ihr als Entwickler habt, und ordentlichen
00:36:38.224 --> 00:36:41.825
Code zu produzieren. Also schmeißt
Compiler-Warnungen nicht weg, lest sie und
00:36:41.825 --> 00:36:46.801
versucht, sie weg zu machen. Und zwar
nicht mit einem Pragma. Die nächste
00:36:46.801 --> 00:36:53.313
Dimension ist: Welchen Anspruch hat der
Typ überhaupt? Das ist mir aufgefallen -
00:36:53.313 --> 00:36:58.917
es gab, ich glaube, libexiv2. Das ist so
eine Software, um Metadaten in Digital-
00:36:58.917 --> 00:37:04.896
Kamera-Bildern zu lesen. Da steht so drin,
irgendwie GPS-Koordinaten und was das für
00:37:04.896 --> 00:37:09.333
eine Linse war, und so. Und das ist halt so mehr
oder weniger wohl definiert, wie dieser
00:37:09.333 --> 00:37:12.456
Standard aussieht. Und es gibt eine
OpenSource-Library dafür und da gab's es
00:37:12.456 --> 00:37:15.758
einen Haufen Bugs drin und dann hat der
Autor von dieser Software irgendwann
00:37:15.758 --> 00:37:19.001
einfach geschrieben: "Ja, das dürft ihr
halt nicht anwenden auf
00:37:19.001 --> 00:37:23.259
unvertrauenswürdige Dateien." Das heißt,
der hat nie den Anspruch gehabt, dass
00:37:23.259 --> 00:37:26.800
das sicher ist. Aber das stand halt nicht
dran, und die Leute haben seine Software
00:37:26.800 --> 00:37:30.960
benutzt und angenommen: "Ja, der wird
schon darauf geachtet haben." Daher glaube
00:37:30.960 --> 00:37:35.492
ich, dass Erste und Beste, was wir machen
können, was tatsächlich eine Auswirkung
00:37:35.492 --> 00:37:39.209
hat, ist, wenn wir anfangen, an die
Software zu schreiben, was eigentlich der
00:37:39.209 --> 00:37:42.595
Anspruch war. Also was glauben wir, was
wir erreicht haben? Was haben wir
00:37:42.595 --> 00:37:47.263
überhaupt versucht. So das ist, glaube
ich, wichtig. Eine andere Sache, die es
00:37:47.263 --> 00:37:52.198
hier gab, war, dass Leute Features machen,
die nach Sicherheit klingen. So, das war
00:37:52.198 --> 00:37:55.821
eine Sache, die ich bei Microsoft mal
erlebt habe. Da gab es eine Feature namens
00:37:55.821 --> 00:37:59.210
"Network Access Protection", und dann bin
ich da hingegangen für Thread Modelling
00:37:59.210 --> 00:38:02.628
und wollte wissen: "Was sind eure eure
Security Guarantees? Was sagt ihr denn
00:38:02.628 --> 00:38:06.296
zu?" Und da meinten die so: "Ja, gar
nichts. Wir sind kein Security-Feature."
00:38:06.296 --> 00:38:10.513
Meinte ich so: "Ja, dann ist der Name
vielleicht ein bisschen verwirrend." Aber
00:38:10.513 --> 00:38:14.693
sowas passiert halt, weil es einen
Disconnect gibt zwischen den Leuten, die
00:38:14.693 --> 00:38:20.115
das Projekt machen, und denen, die den
Namen wählen und das Marketing machen. Ja,
00:38:20.115 --> 00:38:25.190
gut, da gibts auch nochmal Abstufungen. Es
gibt halt so explorative Software.
00:38:25.190 --> 00:38:28.810
Übrigens, fast alle Open Source Software,
die ich so veröffentlicht habe, ist auch
00:38:28.810 --> 00:38:32.660
explorativ. Das ist nicht negativ gemeint
- im Gegenteil, das ist der beste Weg, wie
00:38:32.660 --> 00:38:36.058
man Programmieren lernen kann. Ich habe
etwas verstanden, wenn ich es einmal
00:38:36.058 --> 00:38:40.541
implementiert habe. Das heißt nicht, dass
die Implementation dann gut war. Das
00:38:40.541 --> 00:38:45.744
versuche ich natürlich. Aber es ist
wichtig, das zu kommunizieren: "Dieser Code
00:38:45.744 --> 00:38:50.294
war explorativ." Der ist jetzt vielleicht
gut genug abgehangen und hat genug
00:38:50.294 --> 00:38:55.405
Real-Life-Tests gemacht und Interoperabilität,
dass man ihm trauen kann. Aber der
00:38:55.405 --> 00:39:00.857
Anspruch war explorativ. Oder es gibt
dieses Szenario: "The guy left."
00:39:00.857 --> 00:39:04.590
Das erlebt man gelegentlich bei großen
Firmen. "Ja, wir haben hier noch ein Stück
00:39:04.590 --> 00:39:07.374
Code, aber wir wissen gar nicht, wer das
geschrieben hat." Oder: "Wir wissen schon,
00:39:07.374 --> 00:39:11.371
wer das geschrieben hat, aber das war
einer der Gründer, und der hat jetzt keine
00:39:11.371 --> 00:39:16.050
Zeit mehr für sowas." Oder: "Der Typ, der
ist in Ruhestand gegangen", oder
00:39:16.050 --> 00:39:20.072
so. Das kommt alles vor. Und das finde
ich aber wichtig, dass man das
00:39:20.072 --> 00:39:24.693
kommuniziert, weil die Leute, die das
benutzen, die wissen, dass halt nicht.
00:39:24.693 --> 00:39:29.356
Oder was üblicherweise das beste Szenario
ist, vom Anspruch her, ist, dass der Typ,
00:39:29.356 --> 00:39:33.258
der das entwickelt, auch der aktuelle
Maintainer ist und am Besten versucht, das
00:39:33.258 --> 00:39:36.727
kommerziell zu vermarkten, weil der hat
dann wirklich ein Interesse daran, dass es
00:39:36.727 --> 00:39:40.252
ordentlich wird in den meisten Fällen.
Gut, es gibt immer noch mehr Dimensionen,
00:39:40.252 --> 00:39:42.612
tut mir leid, dass es so ein komplexes
Problem ist.
00:39:42.612 --> 00:39:45.735
Es gibt auch das Problem, dass der Typ,
00:39:45.735 --> 00:39:51.611
der das umsetzt, die besten Intentionen
hatte und die besten Techniken
00:39:51.611 --> 00:39:56.651
benutzt, die es gibt, aber dass die Spec,
die er umsetzt, scheiße ist. Zum Beispiel
00:39:56.651 --> 00:40:00.428
ist XML eine Spec, die richtig scheiße
ist. Da stehen Sachen drin, wie, dass man
00:40:00.428 --> 00:40:03.856
eine Entity-Expansion machen muss, und
damit kann man einen ganz trivial einen
00:40:03.856 --> 00:40:07.917
DoS-Angriff machen - auf, im Grunde jeden
standardkonformen XML-Parser. Und dann
00:40:07.917 --> 00:40:11.881
haben die alle angefangen, irgendwie
Konfiguration nachzurüsten, wo man das
00:40:11.881 --> 00:40:15.607
ausschalten kann. Aber damit ist man
eigentlich nicht mehr standardkonform.
00:40:15.607 --> 00:40:19.101
Das kommt häufiger vor, dass Specs
schlecht sind. Das ist kein Einzelfall.
00:40:19.101 --> 00:40:23.064
Ich will jetzt nicht auf XML zeigen,
andere sind auch nicht gut. Oder JSON-
00:40:23.064 --> 00:40:27.135
Parser: Da gab es jetzt ein paar Versuche,
da sind die Leute einfach herumgegangen
00:40:27.135 --> 00:40:31.788
und haben ganz viele Rekursionstiefen
aufgemacht und plötzlich platzten die
00:40:31.788 --> 00:40:36.450
Parser alle. Oder Window-Messages bei
Windows ist ein ganz altes Problem. Das
00:40:36.450 --> 00:40:40.591
ist halt erfunden worden, bevor es mehr
als einen User gab. Oder so Message-Bus
00:40:40.591 --> 00:40:45.691
allgemein, ist so eine Sache, die häufig
in so Cloud-Installationen und in großen
00:40:45.691 --> 00:40:49.752
Firmen gesehen werden kann. Dass die Leute
sagen: "Okay, wenn wir das über die
00:40:49.752 --> 00:40:53.954
Datenbank machen, ist es zu langsam. Also
bauen wir hier noch ein Message-Bus drum
00:40:53.954 --> 00:40:58.110
rum." Und dann kann aber jeder, der
Zugriff auf den Message-Bus hat,
00:40:58.110 --> 00:41:03.000
auch spoofen oder kann alle anderen Daten
sehen. Das ist die Idee schon schlecht
00:41:03.000 --> 00:41:06.210
und es ist egal, wie gut ich das
umsetze - das wird dadurch nicht
00:41:06.210 --> 00:41:11.460
besser. Dann gibt's noch so Lock-In-
Probleme. Da weiß ich nicht, ob die hier
00:41:11.460 --> 00:41:14.430
wirklich rein gehören, aber ich finde das
wichtig genug, dass, wenn wir schon dabei
00:41:14.430 --> 00:41:19.740
sind, hier Labels zu vergeben, das
auch erwähnen sollten. Zum Beispiel
00:41:19.740 --> 00:41:23.460
irgendeine Library, die eigentlich genau
das tut, was ich haben will. Aber sie
00:41:23.460 --> 00:41:29.310
läuft nur in der Amazon-Cloud. Dann hab
ich meine Freiheit, welche Plattform ich
00:41:29.310 --> 00:41:32.400
verwende, eingeschränkt, wenn ich diese
Library reinziehe. Das ist eigentlich auch
00:41:32.400 --> 00:41:40.080
eine Sache, die man vorher kommunizieren
müsste - und zwar klar. Oder bei Cryptocode
00:41:40.080 --> 00:41:44.070
war lange Zeit ein Problem, dass der
assembler-handoptimiert war für die Intel-
00:41:44.070 --> 00:41:48.300
Architektur. Aber wenn man dann so
Randgruppen-Plattformen wie
00:41:49.020 --> 00:41:54.660
PowerPC, MIPS oder sogar ARM hatte, dann
lief das halt nicht gut. Das ist jetzt ist keine
00:41:54.660 --> 00:42:01.480
harte Abhängigkeit, aber es schränkt
den Benutzer ein. Wenn wir schon
00:42:01.480 --> 00:42:04.990
dabei sind, dann können wir auch gleich
noch den Ressourcen-Footprint reinziehen.
00:42:04.990 --> 00:42:08.170
Es gibt ja häufig so Sachen: "Ja, wir
müssen hier sortieren, aber wir rechnen
00:42:08.170 --> 00:42:12.070
nur mit zehn Elementen - also machen wir
Bubbelsort." Und dann kommt jemand
00:42:12.070 --> 00:42:16.060
und tut mehr Elemente rein und
plötzlich platzt das. Das ist eigentlich
00:42:16.060 --> 00:42:19.240
auch eine Sache, die man kommunizieren
sollte: "Mit welchen Größenordnungen gehen
00:42:19.240 --> 00:42:25.810
wir hier eigentlich um? Worauf ist das
ausgelegt?" Und Achtung! Es geht nicht nur
00:42:25.810 --> 00:42:29.020
um CPU, es geht auch um den RAM-Bedarf.
Und es geht auch darum, dass zum Beispiel
00:42:29.020 --> 00:42:33.160
eine Library ständig auf der Platte
rumschreibt und I/O-Bandbreite frisst oder
00:42:33.160 --> 00:42:39.310
versucht, aus dem Netz irgendwas
nachzuladen. Also nehmen
00:42:39.310 --> 00:42:42.040
wir mal an, das sind die
Dimensionen. Es ist ein bisschen
00:42:42.040 --> 00:42:44.950
schwierig, da eine Metrik daraus zu bauen,
denn eine gute Metrik ist ja immer
00:42:44.950 --> 00:42:48.070
zwischen 0 und 1 oder, sagen wir, 0 und
10, das heißt, man hat eine
00:42:48.070 --> 00:42:51.880
Vergleichbarkeit. Aber wenn ich sage, wir
müssen transitiv die Probleme der
00:42:51.880 --> 00:42:55.120
Dependencies mit reinziehen,
dann haben wir die Skala nicht,
00:42:55.120 --> 00:42:58.420
weil die kann dann beliebig groß werden,
wenn ich mehr Dependencies reinziehe.
00:42:58.420 --> 00:43:05.530
Daher glaube ich, von diesem Metrik- bzw.
Scoreproblem müssen wir weg. Und es gibt
00:43:05.530 --> 00:43:08.680
das Problem, wenn ich eine Metrik habe,
dass die Leute dann Gaming betreiben, um
00:43:08.680 --> 00:43:13.150
die Metrik zu schönen und nicht das
Problem zu lösen. Da dachte ich mir:
00:43:13.150 --> 00:43:17.980
"Nennen wir es mal Legacy-Score...
aber Score geht eigentlich nicht... hmm...
00:43:17.980 --> 00:43:23.380
was kann man denn noch machen? Und vor
allem wofür gilt denn die Metrik dann? Da gibt's
00:43:23.380 --> 00:43:26.740
eigentlich auch verschiedene Ansätze, was
man sagen kann..." Man könnte sagen für die
00:43:26.740 --> 00:43:31.570
gesamte Software, dass sich so eine Art
Score ausrechne. Und das ist wie, sag ich
00:43:31.570 --> 00:43:35.260
mal, bei einer Versicherung, dass sie halt
guckt, wie viel, wie wahrscheinlich ist
00:43:35.260 --> 00:43:39.820
es, dass ich hier zahlen muss? So in der
Richtung Risikobewertung. Oder ich kann
00:43:39.820 --> 00:43:43.420
das für ein Modul machen. Oder
für Manager, dass der Manager sagt:
00:43:43.420 --> 00:43:47.980
"Das Modul ziehen wir nicht rein, das ist
zu riskant." Oder für Entwickler. Oder
00:43:47.980 --> 00:43:52.210
vielleicht sogar pro Funktion? Und da hab
ich mir gedacht: "Okay, gucken wir doch
00:43:52.210 --> 00:43:55.090
mal, was es da für Prior Art gibt, was
haben die Leute denn bisher gemacht?" Und
00:43:55.090 --> 00:43:58.570
ich habe einen schönen Standard gefunden
von 1993: Kompakte Darstellung
00:43:58.570 --> 00:44:01.930
mehrdimensioneller Daten, nämlich, den
Geek Code. Wer hier kennt den Geek Code?
00:44:01.930 --> 00:44:08.480
Das jetzt für die älteren unter euch. Das
sah so aus: die Formatierung
00:44:08.480 --> 00:44:13.310
war so ein bisschen als als Scherz auf
PGP. Die Idee war, dass man sich selbst
00:44:13.310 --> 00:44:17.990
beschreibt. Also GED heißt zum Beispiel
Geek Education Sector. Und danach? Das
00:44:17.990 --> 00:44:22.460
sind alles irgendwelche Dimensionen. Und
dann eine Bewertung. Zum Beispiel: s heißt:
00:44:22.460 --> 00:44:28.370
"Wie groß bin ich?" Und das haben die Leute
in ihre Signature getan und im Usenet
00:44:28.370 --> 00:44:31.370
verbreitet. Und dann konnte man so grob
sich eine Vorstellung machen, was der
00:44:31.370 --> 00:44:34.700
andere Typ ist, welche Interessen er hat.
Ich finde das nicht gut für Typen. Das war
00:44:34.700 --> 00:44:38.870
sozusagen der Vorgänger von Facebook
könnte man aus heutiger Sicht sagen. Die
00:44:38.870 --> 00:44:42.320
Leute haben freiwillig alles Mögliche über
sich verraten. Aber die Idee ist ja
00:44:42.320 --> 00:44:44.480
vielleicht nicht schlecht und habe ich mir
gedacht: "Jetzt versuchen wir
00:44:44.480 --> 00:44:48.500
doch mal, die Dimensionen, die ich hier
formuliert habe, auf so eine Art Score
00:44:48.500 --> 00:44:53.810
abzubilden." Und das ist gar nicht so
einfach, deswegen habe ich auch den
00:44:53.810 --> 00:44:56.360
Vortrag hier erst einmal auf deutsch
gemacht, bevor ich das international
00:44:56.360 --> 00:44:59.630
vortrage, weil ich glaube, da muss noch
gefeilt werden. Ich würde mich über euer
00:44:59.630 --> 00:45:03.440
Feedback da auch wirklich freuen, wenn ihr
noch Vorschläge habt. Ich zeig jetzt mal
00:45:03.440 --> 00:45:07.940
den Entwurf, den ich gemacht habe bisher.
Die Idee wäre, dass man es als Autor
00:45:07.940 --> 00:45:11.570
von einer Library in einen Kommentar
reinschreibt, oben. Und dann hat man so
00:45:11.570 --> 00:45:15.770
eine Art, ich sage mal, Hundepfeife. Der
andere Entwickler kann es lesen und
00:45:15.770 --> 00:45:21.800
versteht, was gemeint ist. Das hier ist
jetzt noch relativ klar: "Wer besitzt
00:45:21.800 --> 00:45:26.690
eigentlich den Code?" Und da ist der
schlimmste Fall natürlich: man sieht
00:45:26.690 --> 00:45:29.960
den gar nicht. Man hat nicht mal eine
Kopie davon, sondern das läuft irgendwo in
00:45:29.960 --> 00:45:33.770
der Cloud. Das wäre hier klar die
Dimension. Dann... das ist so ein bisschen
00:45:33.770 --> 00:45:37.070
verwandt, aber nicht genau dasselbe:
"Ich habe den Code, und ich kann ihn
00:45:37.070 --> 00:45:41.210
ändern." Oder: "Ich kann ihn nur lesen",
sowas. Oder: "Der ist verloren gegangen." Oder
00:45:41.210 --> 00:45:51.530
so das Huawei Modell: "Wir lassen die
Regierung reingucken." Ja, das ist jetzt so
00:45:51.530 --> 00:45:54.320
ein bisschen mit dem scherzenden Auge
natürlich, aber ich finde die Idee
00:45:54.320 --> 00:45:59.720
eigentlich, muss ich sagen, ganz
attraktiv. Ich werde das bei meinem
00:45:59.720 --> 00:46:05.150
eigenen Code mal einbauen. Das
Problem bei sowas ist natürlich, dass man
00:46:05.150 --> 00:46:08.750
gucken muss, dass das obere Ende auch
tatsächlich das obere Ende ist und nur von
00:46:08.750 --> 00:46:13.080
wenigen erreicht werden wird. Dass jemand
tatsächlich Sicherheitszusagen macht, ist
00:46:13.080 --> 00:46:19.020
sehr selten. Eigentlich fast nie. Dann
gibt es so Leute, die machen seit 20
00:46:19.020 --> 00:46:22.200
Jahren immer nur dasselbe. Zum Beispiel
der Typ, der Zstandard macht, das so eine
00:46:22.200 --> 00:46:26.130
Kompressions-Library, die jetzt über
Facebook released wurde, der hat vorher
00:46:26.130 --> 00:46:30.780
LZ4 gemacht und macht seit Ewigkeiten
Kompressosions-Algorithmen. Da kann man
00:46:30.780 --> 00:46:35.250
annehmen, der weiß grob, was er tut. Das geht
aber runter bis zu: "Ich bin ja nicht
00:46:35.250 --> 00:46:38.490
der Typ, der das geschrieben hat, sondern
ich muss es hier nur verwalten. Ich hab
00:46:38.490 --> 00:46:42.990
das geerbt, ich bin hier der Azubi." Das
müsste eigentlich dran stehen, finde ich.
00:46:44.340 --> 00:46:48.390
Wie sieht es denn mit der Korrektheit aus?
Das ist ja auch ein Problem. Und das geht
00:46:48.390 --> 00:46:51.420
halt von: "Ich habe einen Beweis, und den
kannst du nachvollziehen." Bis über: "Ich
00:46:51.420 --> 00:46:56.460
habe einen Beweis, und den kannst du nicht
nachvollziehen." Oder: "Naja, wir versuchen
00:46:56.460 --> 00:47:00.480
immer, alle Bugs zu schließen", wobei
schließen und fixen ein Unterschied ist.
00:47:00.480 --> 00:47:05.850
Also aufgepasst! Immer schön in den
Bugtracker gucken. Und dann gibt's halt die
00:47:05.850 --> 00:47:09.000
Leute, die argumentieren: "Ja, das ist
doch gar kein Security Problem, der crasht
00:47:09.000 --> 00:47:14.670
doch bloß." Also Leute, die entweder keine
Ahnung haben oder böswillig sind. Und das
00:47:14.670 --> 00:47:18.810
finde ich wichtig, das zu kommunizieren.
Die meisten Leute sind hier bei Stand C-,
00:47:18.810 --> 00:47:24.090
da draußen, oder sie haben überhaupt
keinen Bugtracker. Das gibt's auch noch
00:47:24.090 --> 00:47:28.920
vereinzelt. Dann hab ich mir gedacht:
"Vielleicht müssen wir noch sagen:
00:47:28.920 --> 00:47:33.540
'Welche Art von Design ist denn in die
Entwicklung eingeflossen?'" Das geht halt
00:47:33.540 --> 00:47:37.470
los mit: "Ja, alle Buzzwords angeklickt.
Wir haben hier Least Privilege usw."
00:47:37.470 --> 00:47:42.540
Dann gibt es einen relativ großen
Sprung zu: "Naja, wir validieren unsere
00:47:42.540 --> 00:47:48.070
Inputs." Das ist schon mal gut, aber es
geht halt bis runter zu so
00:47:48.070 --> 00:47:51.232
Bullshit-Blabla, von wegen: "Ja, wir haben
doch einen Anti-Virus."
00:47:51.232 --> 00:47:53.575
Publikum lacht
00:47:53.575 --> 00:47:59.176
Und ich finde, das wäre eigentlich schön,
wenn man es an der Software hätte. So eine
00:47:59.176 --> 00:48:06.097
Art Label. Die Idee kam mir
eigentlich, als ich mal in Amerika so eine
00:48:06.097 --> 00:48:10.152
Multi-Vitamin-Tabletten-Packung gekauft
habe, denn da ist hinten so eine riesige
00:48:10.152 --> 00:48:14.255
Tabelle drauf, mit den Supplement Facts
und da steht drauf: "Dieses Vitamin, so
00:48:14.255 --> 00:48:18.012
und so viel Prozent der Recommended Daily
Allowance." Und da kann man dann sehen:
00:48:18.012 --> 00:48:22.567
"Okay, die wollen mich verarschen." Weil da
steht dann sowas wie: "Vitamin C: 5000%"
00:48:22.567 --> 00:48:27.432
So: "Viel hilft viel." Also ich
meine, da muss man natürlich trotzdem, als
00:48:27.432 --> 00:48:31.606
der, der dieses Label liest, ein grobes
Verständnis haben, was das bedeutet. Aber
00:48:31.606 --> 00:48:36.538
immerhin. Ich glaube, das ist ein Weg, den
wir mal ausprobieren können. Übrigens das
00:48:36.538 --> 00:48:42.133
hier unten: "The author left" und "project
abandoned" ist häufiger, als man glaubt.
00:48:42.133 --> 00:48:46.668
Volatility: das versucht, so ein
bisschen dieses Agilitätsproblem
00:48:46.668 --> 00:48:51.040
anzugehen. Dass Leute einfach häufiger
releasen, als man prüfen kann, ob das
00:48:51.040 --> 00:48:55.159
jetzt ordentlich ist oder nicht. Aber so
richtig eine gute Lösung gibt es
00:48:55.159 --> 00:48:59.743
eigentlich nicht. Was ich so persönlich
als am entspanntesten empfinde, ist Vim.
00:48:59.743 --> 00:49:04.345
Vim bringt im Grunde täglich Updates raus,
aber man merkt nie, dass sich irgendwas
00:49:04.345 --> 00:49:08.893
verändert hat. Weil die Software compiled
vorher und nachher, alle Sachen, die ich
00:49:08.893 --> 00:49:13.706
benutzt habe, gehen noch. Das ist, glaube
ich, das Optimalziel, was man da erreichen
00:49:13.706 --> 00:49:17.203
kann bei Software, dass der Kunde gar
nicht merkt, ob gepatcht wurde oder nicht,
00:49:17.203 --> 00:49:20.885
weil das einfach alles weiter
funktioniert. Die Spec hatte ich ja schon
00:49:20.885 --> 00:49:26.271
erwähnt. Die müssen wir auch irgendwie
abbilden, ob die Spec was taugt. Und da
00:49:26.271 --> 00:49:31.933
gibt es auch ein großes Spektrum: Dass die
Spec offen, kurz und verständlich ist, ist
00:49:31.933 --> 00:49:36.007
leider auch selten. Häufig kommt es vor,
dass die Spec hinter einer Paywall ist,
00:49:36.007 --> 00:49:39.835
und das ist dann so gut, als wenn es gar
keine Spec gäbe, weil ich als Open-Source-
00:49:39.835 --> 00:49:44.031
Typ werde jetzt nicht zur ISO laufen und
mir für ein paar tausend Euro irgendwie
00:49:44.031 --> 00:49:49.421
die MPEG-Spec runterladen um zu gucken, ob
der MPEG-Player ordentlich ist, den ich da
00:49:49.421 --> 00:49:54.225
gerade runtergeladen hab. Dann haben
wir noch Dependecies. Das müsste man
00:49:54.225 --> 00:49:57.723
eigentlich transitiv machen, da ist mir
jetzt auch nicht klar, wie man das auf den
00:49:57.723 --> 00:50:01.824
Score abbildet. Wenn einer von euch eine
Idee hat, bin ich da gerne für zu haben.
00:50:01.824 --> 00:50:06.636
Also wie sieht das in der Praxis
aus? Ich habe hier mal versucht, ein paar
00:50:06.636 --> 00:50:10.657
Beispiele zu machen - ungefähr so. Das
Problem ist halt, dass die Dimensionen
00:50:10.657 --> 00:50:15.330
jeweils auf beiden Seiten subjektiv sind.
Das heißt, für den einen oder anderen ist
00:50:15.330 --> 00:50:20.768
es vielleicht okay, wenn er den Quellcode
nicht hat, solange es noch Wartungen gibt.
00:50:20.768 --> 00:50:25.259
Also Leute, die Windows einsetzen, zum
Beispiel. Für die ist es okay,
00:50:25.259 --> 00:50:29.070
wenn es den Quellcode nicht
gibt. Aber das heißt eben, dass der
00:50:29.070 --> 00:50:33.399
Score auch nicht einfach eine Zahl sein
kann, sondern er muss pro Dimensionen
00:50:33.399 --> 00:50:38.295
einen Wert haben. Das sieht jetzt irgendwie
schwer zu lesen aus - und ist es auch.
00:50:38.295 --> 00:50:43.166
Aber bei dem Geek Code hat sich
herausgestellt: wenn man so ein paar Tage
00:50:43.166 --> 00:50:47.637
macht, dann gewöhnt man sich dran. Und ich
glaube, das ist eine ganz gute Idee. Ich
00:50:47.637 --> 00:50:51.557
hab mir dann noch überlegt: "Eigentlich
brauchst du jetzt noch eine schöne Domain."
00:50:51.557 --> 00:50:56.079
Habe mir überlegt: "legacyco.de wäre
super!", aber die hat schon Xing gekauft.
00:50:56.079 --> 00:50:59.108
Publikum lacht
00:51:00.042 --> 00:51:05.852
Ja gut, das war so mein Vorschlag. Ich hoffe,
ich kriege jetzt eine Menge gute Ideen,
00:51:05.852 --> 00:51:09.893
was man da noch verbessern kann oder
vielleicht auch andere Vorschläge, die
00:51:09.893 --> 00:51:14.282
keinen Score beinhalten. Vielleicht ist ja
auch der ganze Ansatz schon falsch. Aber
00:51:14.282 --> 00:51:18.240
ich bin mir sicher, dass wir als Industrie
jetzt mal loslegen müssen. Ich glaube,
00:51:18.240 --> 00:51:22.553
reaktiv funktioniert das nicht, sondern
wir müssen gucken, wie wir im
00:51:22.553 --> 00:51:26.820
Entwicklungsprozess erstens dafür sorgen,
dass die Leute die Entscheidungen, welche
00:51:26.820 --> 00:51:30.654
Produkte sie reinziehen, welche
Dependencies sie reinziehen, auf
00:51:30.654 --> 00:51:36.671
informierter Grundlage treffen können. Ich
hätte gern, dass es so einen Score gibt,
00:51:36.671 --> 00:51:41.510
wo man dann auch als Entwickler einen
Anreiz hat, das besser werden zu lassen,
00:51:41.510 --> 00:51:46.426
weil man sehen kann: "An der Stelle
bin ich noch nicht der Standard,
00:51:46.426 --> 00:51:49.610
der ich sein möchte." Ansonsten,
wir haben jetzt die
00:51:49.610 --> 00:51:53.647
Saal-Mikrofone. Ich hoffe, die Signal-
Engel sind schon so weit. Ansonsten, Fragen
00:51:53.647 --> 00:51:58.069
nehme ich auch gern per Mail entgegen.
Vielen Dank für die Aufmerksamkeit.
00:51:58.069 --> 00:52:09.897
Applaus
00:52:10.565 --> 00:52:13.514
Herold: Dann können jetzt alle an die
Mikrofone gehen, die noch Fragen haben.
00:52:13.514 --> 00:52:16.685
Wir haben direkt eine Frage aus dem
Internet. Bitte!
00:52:16.685 --> 00:52:20.779
Anonym: Gibt es Projekte im echten Leben,
wo das Problem mit der Komplexität deiner
00:52:20.779 --> 00:52:24.503
Meinung nach richtig gemacht wurde? Und
wenn ja, wo findet man die?
00:52:24.503 --> 00:52:30.910
Fefe: Sehr selten. Es gab einmal
vor ein paar Jahren gab es so einen Push,
00:52:30.910 --> 00:52:34.660
wo viele Leute angefangen haben, Software
zu veröffentlichen und damit zu bewerben,
00:52:34.660 --> 00:52:40.990
dass sie besonders klein oder minimal sein
soll. Da bin ich auch einer von. Aber es
00:52:40.990 --> 00:52:44.440
stellt sich halt raus, dass es auch andere
Projekte gibt, die halt minimal dran
00:52:44.440 --> 00:52:47.110
schreiben, weil sie finden, es sei
minimal, und das ist dann aber nicht
00:52:47.110 --> 00:52:52.030
minimal. Zum Beispiel gab es neulich ein
Announcement von einem Systemd-Clone in
00:52:52.030 --> 00:52:56.830
Rust, und ich bin eigentlich ein Fan von
Rust und kein Fan von Systemd. Deswegen
00:52:56.830 --> 00:53:01.990
fände ich da ein Ersatz schon
gut. Aber Rust erzeugt keine kleinen
00:53:01.990 --> 00:53:06.370
Binaries, sondern da fallen so große
Monster raus. Das heißt, das ist dann zwar
00:53:06.370 --> 00:53:11.620
minimal im Sinne von, wie viel Features es
implementiert, aber das Endprodukt ist
00:53:11.620 --> 00:53:15.280
halt riesig groß. Da kann jetzt der Typ
nichts für, der das geschrieben hat. Das
00:53:15.280 --> 00:53:19.182
ist im Moment noch ein Rust-Problem,
und da arbeiten die auch dran.
00:53:19.182 --> 00:53:24.310
Aber "minmal", "Komplexität", "gering",
ist eine subjektive Sache. Ich
00:53:24.310 --> 00:53:28.360
persönlich habe immer die Software von
Dan[iel] Bernstein sehr gut gefunden, also
00:53:28.360 --> 00:53:32.980
qmail und djbdns sind gute Beispiele
dafür, wie ein Code aussieht, der
00:53:32.980 --> 00:53:38.800
Komplexität gut managed und klein hält.
Aber es ist ein kleines Feld. Man findet
00:53:38.800 --> 00:53:44.970
da nicht so viele Beispiele von Software,
die gut gemacht und unterkomplex ist.
00:53:46.505 --> 00:53:52.170
Herold: Dann, am Mikrofon 10 hatte ich
gesehen. Kann das sein? Ich habe gerade
00:53:52.170 --> 00:53:56.280
ein Signal bekommen... Nein? Alles klar.
Da machen wir weiter mit Mikrofon zwei.
00:53:56.280 --> 00:53:59.574
Bitte!
Anonym: Vielen Dank für die spannenden
00:53:59.574 --> 00:54:04.830
Ideen! Meine Frage geht so ein bisschen
auf: Ist das nicht zu freiwillig und zu
00:54:04.830 --> 00:54:08.150
selbst auferlegt? Ist das nicht zu CDU-
mäßig als Lösung?
00:54:08.150 --> 00:54:11.454
Fefe lacht
Was hält nicht davon ab, einfach zu sagen
00:54:11.454 --> 00:54:15.160
Ich bin M+++, obwohl ich das vielleicht
gar nicht bin?
00:54:15.160 --> 00:54:20.400
Fefe: Das ist in der Tat ein Problem, und
ich bin mir auch nicht sicher, wie und ob
00:54:20.400 --> 00:54:24.602
man das lösen kann. Ich glaube aber, wenn
man anfängt und das so ein bisschen
00:54:24.602 --> 00:54:29.619
losgeht, dass es dann auch ein Druck gibt
aus der Community, der die Leute davon
00:54:29.619 --> 00:54:34.831
abhält zu lügen. Also meine Erfahrung mit
Entwicklern ist, dass die meisten Leute
00:54:34.831 --> 00:54:38.848
eigentlich gute Menschen sind. Die
möchten keinen Scheiß machen, niemand
00:54:38.848 --> 00:54:43.162
möchte lügen. Das heißt, wenn du denen
eine Gelegenheit gibst darzustellen, dass
00:54:43.162 --> 00:54:46.937
das noch nicht fertig ist, dann werden sie
das auch tun, im Allgemeinen. Außer du
00:54:46.937 --> 00:54:50.271
hast jemanden, der es wirklich nicht
beurteilen kann. Das Risiko kriegst du mit
00:54:50.271 --> 00:54:54.463
dem Label nicht weg. Aber ich glaube, es
ist schon mal ein guter Schritt, wenn wir
00:54:54.463 --> 00:54:58.681
den den Entwicklern, die gerade dabei
sind, sich eine Dependancy ins Projekt zu
00:54:58.681 --> 00:55:02.985
ziehen, irgendwas in die Hand geben, woran
sie erkennen können: "Ist das denn jetzt
00:55:02.985 --> 00:55:07.257
ernst gemeint, oder war das hier nur so
ein Spielprojekt?" Und ich glaube, das ist
00:55:07.257 --> 00:55:10.891
ein guter Anfang. Aber ich weiß es
natürlich auch nicht. Müssen wir
00:55:10.891 --> 00:55:17.549
ausrollen, müssen wir gucken.
Herold: Dann am Mikrofon 6, war zuerst.
00:55:17.549 --> 00:55:24.453
Anonym: Das geht vielleicht auch jetzt in
dieselbe Richtung wie der Fragende vor
00:55:24.453 --> 00:55:31.290
mir. Vielleicht. Könnte man wie so eine
Art Rechtsprechungs-Instanz installieren?
00:55:31.290 --> 00:55:37.701
Ich meine, kein Entwickler-Team aus Indien
wird das als Malus akzeptieren, wenn da
00:55:37.701 --> 00:55:43.140
dran steht: Entwickler-Team in Indien hat
jetzt das gemacht. Hältst du das für eine
00:55:43.140 --> 00:55:46.838
sinnvolle Idee? Wie könnte man das
umsetzen?
00:55:47.361 --> 00:55:51.361
Fefe: Also es ging jetzt nicht um Indien,
das hätte auch Massachusetts sein können,
00:55:51.361 --> 00:55:54.725
sondern es geht darum, dass das Team halt
nicht der ist, der das geschrieben hat,
00:55:54.725 --> 00:55:58.953
sondern irgendjemand hat es jetzt halt am
Bein, weil wir brauchten einen Maintainer.
00:55:58.953 --> 00:56:04.293
Das ist immer ein Problem. Und natürlich
wird es auch irgendwie Betrüger geben.
00:56:04.293 --> 00:56:09.630
Aber ich hoffe, dass man die dann erkennt,
weil die halt in allen Feldern das Beste
00:56:09.630 --> 00:56:13.611
jeweils anklicken. Aber ich weiß es halt
auch nicht, das muss man ausprobieren.
00:56:13.611 --> 00:56:17.483
Also meine Erfahrung ist, dass an anderer
Stelle Communities schon helfen, den
00:56:17.483 --> 00:56:21.814
Standard hochzuziehen, wenn man zumindest
einfach mal anfängt und sagt: "Das
00:56:21.814 --> 00:56:26.136
hier ist wichtig, da müssen wir drüber
reden." Und das ist, glaube ich, ein
00:56:26.136 --> 00:56:31.395
Zeichen, wenn es so einen Code gibt, wo es
ein Feld gibt, für: "Wie volatil ist denn
00:56:31.395 --> 00:56:35.428
das?", und supervolatil ist nicht der
höchste Score, dass man vielleicht
00:56:35.428 --> 00:56:39.722
irgendwie auf die Art auch Ideen
transportiert kriegt? Dass man sagt:
00:56:39.722 --> 00:56:44.161
"Vielleicht musst du nochmal drüber
nachdenken, wie du dein Projekt aufziehst."
00:56:45.811 --> 00:56:50.310
Herold: Dann bitte am Mikrofon 1.
Anonym: Ich hab grad drüber
00:56:50.310 --> 00:56:54.073
nachgedacht, ob das nicht so etwas
ähnliches ist, wozu die
00:56:54.073 --> 00:56:57.720
Lebensmittelindustrie so ein bisschen
genötigt werden musste: Alle Inhaltsstoffe
00:56:57.720 --> 00:57:02.270
reinzuschreiben, Allergene reinzuschreiben
und so. Und deshalb die Frage: Sollten wir
00:57:02.270 --> 00:57:06.510
nicht möglichst bald als Follow-Up
entwickeln, so eine Art Software Code-
00:57:06.510 --> 00:57:10.085
Ampel einzuführen. Und dann rot, gelb und
grün daraus zu machen.
00:57:10.085 --> 00:57:12.822
Lacht
Fefe: Ja, genau. Das war ja eigentlich die
00:57:12.822 --> 00:57:16.161
Idee. Aber ich glaube, du kannst es nicht
runterbrechen auf einen Score, weil
00:57:16.161 --> 00:57:19.253
einige Teile davon subjektiv sind. Das ist
ja bei Lebensmitteln eher nicht so,
00:57:19.253 --> 00:57:22.932
sondern da vertraust du der Behörde. Die
Behörde sagt irgendwie so und so viel
00:57:22.932 --> 00:57:26.620
Quecksilber ist Maximum. Und wenn mehr,
ist es nicht gut. Da fängst du nicht
00:57:26.620 --> 00:57:30.078
an zu verhandeln. Aber wenn jetzt die
Software kommt und sagt: "Wir ziehen
00:57:30.078 --> 00:57:33.922
hier noch ein MySQL rein", und du weißt es
nicht besser, dann sagst du halt:
00:57:33.922 --> 00:57:38.379
"Okay". Das ist eine Sache, die muss man
auch dem Endbenutzer überlassen. Weil du
00:57:38.379 --> 00:57:43.382
willst ja auch nicht, zum Beispiel,
OCaml benachteiligen, weil
00:57:43.382 --> 00:57:46.965
da noch keiner von gehört hat. Und dass
die Leute sagen: "Ja wie, da gibts jetzt
00:57:46.965 --> 00:57:51.137
keinen Score für?" Das ist halt nicht
C. Ist es jetzt besser oder nicht? Das
00:57:51.137 --> 00:57:55.221
muss ja offen genug bleiben. Deswegen
glaube ich auch nicht an Schiedsgerichte
00:57:55.221 --> 00:57:58.887
und irgendwie Organisationen, die
Labels vergeben. Das ist doch nie gut
00:57:58.887 --> 00:58:02.851
ausgegangen, in meiner Erfahrung. Ich glaube,
das muss aus der Community kommen,
00:58:02.851 --> 00:58:06.423
und das muss so laufen, dass man das
Gefühl hat, ich tue jetzt hier etwas
00:58:06.423 --> 00:58:09.748
Besseres, und ich kann den Erfolg sehen,
weil mein Score jetzt hier besser wird.
00:58:09.748 --> 00:58:12.763
Ich kann jetzt hier ++ schreiben. Ist
jetzt die Hoffnung. Ich weiß auch nicht,
00:58:12.763 --> 00:58:17.678
ob es geht.
Herold: Dann bitte nochmal Mikrofon 2.
00:58:17.678 --> 00:58:22.130
Anonym: Mir hat eine Dimension gefehlt,
die ein bisschen in Wartungen passt, aber
00:58:22.130 --> 00:58:26.171
nicht perfekt. Wir sind ja hier ein Raum
voller Leute, die Sachen selbst in die Hand
00:58:26.171 --> 00:58:29.487
nehmen. Wie leicht ist es denn
mitzumachen? Wie leicht ist es Bugs selbst
00:58:29.487 --> 00:58:33.347
im Upstream zu fixen? Muss man erstmal einen
Vertrag unterschreiben, wo man alle Rechte
00:58:33.347 --> 00:58:37.136
abtritt, oder? Das ist, glaube ich,
auch noch eine wichtige Dimension.
00:58:37.136 --> 00:58:41.254
Fefe: Das stimmt. Ich habe das versucht
abzubilden, über den: "Ich hab den Code
00:58:41.254 --> 00:58:45.464
und darf ihn ändern." Aber das Problem
ist, dass das derjenige, der das Projekt
00:58:45.464 --> 00:58:49.020
verwaltet, üblicherweise nicht gut
beurteilen kann, sondern der wird immer
00:58:49.020 --> 00:58:53.007
sagen: "Ja, ist alles total offen hier".
Das geht, glaube ich, nicht über so einen
00:58:53.007 --> 00:58:55.981
Score. Aber man kann es natürlich
versuchen.
00:58:57.221 --> 00:59:01.799
Herold: Dann bitte Mikrofon 8.
Anonym: Ist fehlendes IPv6 für dich ein
00:59:01.799 --> 00:59:04.998
Bug oder ein nicht implementiertes
Feature?
00:59:04.998 --> 00:59:10.336
Fefe: Das ist eine der subjektiven Fragen.
Für mich persönlich ist es ein Fehler,
00:59:10.336 --> 00:59:13.820
wenn kein IPv6 drin ist. Aber es gibt
genug Firmen da draußen, die sagen: "Das
00:59:13.820 --> 00:59:17.272
haben wir eh nicht."
Anonym: Danke.
00:59:17.272 --> 00:59:21.804
Herold: Dann bitte Mikrofon 7.
Anonym: Die Intention, dass die Community
00:59:21.804 --> 00:59:26.937
das schon richten wird. Du hattest CVSS
als relativ positives Beispiel
00:59:26.937 --> 00:59:31.625
dargestellt. Vor fünf Jahren war
Heartbleed in OpenSSL, das hat einen CVSS-
00:59:31.625 --> 00:59:36.515
Bug von 5,0 gehabt, und Bruce Schneier
kommentierte: "Auf einer Skala von 1 bis 10
00:59:36.515 --> 00:59:42.040
ist das Wert 11." CVSS ging gerade bis 10.
Ich sehe nicht, dass das so klappen kann,
00:59:42.040 --> 00:59:48.444
und ich finde es gut, dass du aufgezeigt
hast, wie komplex das ist, denn wir haben
00:59:48.444 --> 00:59:54.311
halt keinen Standard. Was bedeutet denn
zum Beispiel eben "minimal"? Oder wenn eine
00:59:54.311 --> 00:59:59.230
Zwei-Faktor-Authentifizierungs-Umgehung
ein Sicherheitsbug ist, ist dann jede
00:59:59.230 --> 01:00:01.970
Anwendung mit einer Ein-Faktor-
Authentifizierung automatisch ein
01:00:01.970 --> 01:00:05.158
Sicherheitsbug?
Fefe: Ja, du hast völlig recht, das sind
01:00:05.158 --> 01:00:10.747
offene Forschungsfragen, wie man
das lösen soll. Ich habe da auch keine
01:00:10.747 --> 01:00:15.679
guten Antworten. Die die Heartbleed Sache
hätte man vielleicht klären können, indem
01:00:15.679 --> 01:00:19.085
man sagt: "Welche Zusagen machen wir
denn?" Wenn die Zusagen gebrochen sind,
01:00:19.085 --> 01:00:22.790
dann ist automatisch Totalschaden. Aber
wir haben halt häufig - ich habe das ja auf
01:00:22.790 --> 01:00:25.730
einer Folie gehabt - Projekte,
die klingen so, als wenn sie ein
01:00:25.730 --> 01:00:29.390
Security Feature implementieren. Und wenn
du sie dann fragst, welche Zusagen sie
01:00:29.390 --> 01:00:33.530
machen, kommt dann halt: "Ja ne, gar
keine. Wer mich einsetzt, ist selber
01:00:33.530 --> 01:00:37.310
schuld." Und da müssen irgendwie von
wegkommen. Ich glaube, das geht nur, wenn
01:00:37.310 --> 01:00:41.630
man bei den Leuten so ein bisschen das
Empfinden schärft dafür, dass sie gerade
01:00:41.630 --> 01:00:45.650
die Legacy von morgen schreiben. Die Leute
tun immer so, als wenn Legacy vom Himmel
01:00:45.650 --> 01:00:49.430
fällt. Das haben wir geerbt. Ne, du
schreibst gerade halt nicht von heute die
01:00:49.430 --> 01:00:54.380
Legacy, sondern die von morgen.
Herold: Dann gab es noch eine Frage aus
01:00:54.380 --> 01:00:57.560
dem Internet, bitte!
Anonym: Ja, bei deinem Bewertungsschema:
01:00:57.560 --> 01:01:02.150
Wie soll das bei Projekten funktionieren,
bei denen es gar keinen Owner mehr gibt,
01:01:02.150 --> 01:01:08.030
der das dranschreiben könnte?
Fefe: Naja, irgendwann, wenn sich das gut
01:01:08.030 --> 01:01:11.210
genug durchsetzt, ist die Abwesenheit
eines Labels an sich schon ein schlechtes
01:01:11.210 --> 01:01:16.280
Zeichen. Aber das wird natürlich ewig
dauern, bis wir so weit sind. Also ist nur
01:01:16.280 --> 01:01:20.000
ein Ansatz. Das kann ich auch nicht lösen.
Wenn es niemanden gibt, der das Label dran
01:01:20.000 --> 01:01:24.080
klebt, kann man vielleicht irgendwie eine
Community-Entscheidung auf GitHub machen.
01:01:24.080 --> 01:01:27.472
Eine Verurteilung durch den Mob?
Lachen
01:01:28.688 --> 01:01:33.530
Herold: Dann bitte am Mikrofon 4.
Anonym: Das sind jetzt doch relativ grobe
01:01:33.530 --> 01:01:36.380
Kategorien. Und gerade bei Enterprise
Software als Entwickler wirst du es jetzt
01:01:36.380 --> 01:01:39.530
schwer schaffen, irgendwie bei "Lizenz" eine
Kategorie hochzukommen. Ist denn deine
01:01:39.530 --> 01:01:42.800
Hoffnung, dass tatsächlich Entwickler dazu
angeregt werden, existierende Software zu
01:01:42.800 --> 01:01:45.988
verbessern oder mehr in die Richtung, wenn
ich jetzt eine neue Software mach, dass
01:01:45.988 --> 01:01:48.830
ich mir mal Gedanken mach: "Was will ich
überhaupt erreichen und was für Garantien
01:01:48.830 --> 01:01:52.070
gebe ich?"
Fefe: Das richtet sich vor allem an
01:01:52.070 --> 01:01:57.260
Hobbyisten im Moment, weil im Enterprise
Umfeld sind die sind die Einschränkungen
01:01:57.260 --> 01:02:01.220
der Umgebung andere. Da wirst du halt
bezahlt von der Firma. Und der Typ, der
01:02:01.220 --> 01:02:05.180
dich bezahlt, entscheidet, wofür du deine
Zeit ausgibt. Und da hast du gar nicht die
01:02:05.180 --> 01:02:08.030
Option, jetzt rumzulaufen und den alten
Code besser zu machen, weil es einen
01:02:08.030 --> 01:02:11.960
riesigen Backlog an Sachen gibt, die du
noch machen musst. Besonders so in Agile
01:02:11.960 --> 01:02:17.270
Umfeldern wird ja sozusagen jede freie
Minute noch rausoptimiert. Und da stellt
01:02:17.270 --> 01:02:20.240
sich die Frage gar nicht, ob ich jetzt
rumlaufe und alten Code besser mache.
01:02:20.240 --> 01:02:23.270
Daher glaube ich, wir müssen über Open
Source kommen, und da hätte ich früher
01:02:23.270 --> 01:02:27.500
nicht viel Hoffnung gehabt. Aber Open
Source hat gewaltigen Einfluss ausgeübt
01:02:27.500 --> 01:02:32.760
auf Enterprise Umgebung. Das merkt man
vielleicht aus der Open Source Seite noch
01:02:32.760 --> 01:02:37.500
nicht so. Aber wenn du in Enterprise
Umgebungen unterwegs bist. Fast alle
01:02:37.500 --> 01:02:41.910
größeren Projekte sind alle irgendwie
internetbasiert inzwischen. Selbst
01:02:41.910 --> 01:02:46.920
Appliances haben alle Internet,
und das ist dann zu bestimmt
01:02:46.920 --> 01:02:52.050
60-80% Open Source, je nachdem, in
welcher Branche man da unterwegs ist. Open
01:02:52.050 --> 01:02:55.980
Source hat einen großen Einblick, und als Open
Source anfing zu sagen: "Okay, wir
01:02:55.980 --> 01:02:59.670
müssen agile werden", hat Enterprise
nachgezogen. Daher, glaube ich, werden wir
01:02:59.670 --> 01:03:03.210
es schaffen, als Open Source hier
Standards zu setzen, dass es auch in
01:03:03.210 --> 01:03:06.106
Enterprise rüberschwappt, das ist die
Hoffnung...
01:03:06.818 --> 01:03:11.855
36C3 Musik
01:03:11.855 --> 01:03:40.000
Untertitel erstellt von c3subtitles.de
im Jahr 2020. Mach mit und hilf uns!