1 00:00:00,000 --> 00:00:18,751 *36C3 Intro Musik* 2 00:00:19,571 --> 00:00:23,300 Herald: Jetzt mit dem Talk 'Das nützlich- unbedenklich Spektrum' Ich muss ihn, wie 3 00:00:23,300 --> 00:00:26,625 gesagt, nicht vorstellen: Fefe. 4 00:00:26,625 --> 00:00:30,482 *Applaus* 5 00:00:30,482 --> 00:00:31,482 *Mikrofonklopfen* 6 00:00:37,082 --> 00:00:40,110 Fefe: Ja guten Morgen. Freut mich, dass das alles hier so voll ist. Ein Glück, 7 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 8 00:00:44,340 --> 00:00:46,770 Vortrag, ich muss gleich ein bisschen Erwartungsmanagement machen. Ich habe 9 00:00:46,770 --> 00:00:50,820 nämlich eigentlich letztes Jahr einen anderen Vortrag eingereicht über TCB- 10 00:00:50,820 --> 00:00:54,240 Minimierung und das wäre so ein bisschen technisch gewesen. Was man denn machen 11 00:00:54,240 --> 00:00:59,670 kann als Programmierer. Der ist abgelehnt worden. Ich weiß nicht, warum. War voll. 12 00:00:59,670 --> 00:01:02,520 Den habe ich dieses Jahr wieder eingereicht, aber es sollte nicht so 13 00:01:02,520 --> 00:01:05,520 aussehen, als wenn ich die ärgern will, also habe ich noch einen Talk eingereicht. 14 00:01:05,520 --> 00:01:10,800 Den haben die natürlich genommen.So, das heißt, den musste ich jetzt schnell 15 00:01:10,800 --> 00:01:12,810 vorbereiten. *Publikum lacht* 16 00:01:13,320 --> 00:01:19,290 Ja, das Problem ist, das ist eher so ein Gedankengang als eine strukturierte 17 00:01:19,290 --> 00:01:23,490 Darstellung. Ich hoffe, es wird trotzdem hilfreich. Aber es ist nicht so 18 00:01:23,490 --> 00:01:27,720 strukturiert wie meine sonstigen Vorträge. Ich fange einfach mal an. Also es gibt 19 00:01:27,720 --> 00:01:32,310 mehrere Herleitungen, die im Grunde zum selben Ergebnis führen und ich lasse euch 20 00:01:32,310 --> 00:01:36,540 einfach mal teilhaben.Es fing relativ früh in meiner Karriere an, da habe ich mich 21 00:01:36,540 --> 00:01:40,980 entschieden: ich werde nie Software schreiben, von der vielleicht Leben 22 00:01:40,980 --> 00:01:45,780 abhängen könnten, so medizinische Geräte, Atomkraftwerke, war so meine Vorstellung, 23 00:01:45,780 --> 00:01:51,120 Militär natürlich sowieso nicht. Und dann habe ich aber jemanden getroffen, der Code 24 00:01:51,120 --> 00:01:54,450 für Atomkraftwerke schreibt. Und das war so ein Typ: "Ey das ist doch ganz 25 00:01:54,450 --> 00:02:00,300 einfach." Das heißt, wenn die Leute, die ihre Grenzen einschätzen können, das nicht 26 00:02:00,300 --> 00:02:03,660 machen, dann machen es halt die anderen. *Publikum lacht* 27 00:02:04,630 --> 00:02:08,980 Das soll jetzt nicht verallgemeinernd sein. Ich habe tatsächlich noch einen anderen 28 00:02:08,980 --> 00:02:12,160 getroffen, der war nicht so, aber ich meine, diese Art von Personen gibt es 29 00:02:12,160 --> 00:02:18,220 halt. Die Problematik an der Stelle ist, glaube ich, dass man Programmieren 30 00:02:18,220 --> 00:02:23,350 explorativ lernt: das ist häufig nicht so einen Kurs, den man durchgeht, sondern man 31 00:02:23,350 --> 00:02:28,690 läuft halt rum und sucht Grenzen. Das heißt aber auch, dass man per Definition 32 00:02:28,690 --> 00:02:33,160 die Grenzen noch nicht kennt, denn die will man ja gerade finden. Das heißt aber 33 00:02:33,160 --> 00:02:38,260 auch, dass alle Leute im Grunde immer gerade an ihrer Grenze arbeiten. Wenn 34 00:02:38,260 --> 00:02:41,200 Leute Software schreiben, dann gehen sie so weit, wie sie glauben, dass sie gerade 35 00:02:41,200 --> 00:02:47,320 noch können. Und das heißt aber im Umkehrschluss, dass die Technologie, die 36 00:02:47,320 --> 00:02:50,530 da draußen ausgerollt wird, das sind hauptsächlich eben nicht abgehangene 37 00:02:50,530 --> 00:02:55,240 wohlverstandene Sachen, sondern das sind genau die Technologien, die der Typ gerade 38 00:02:55,240 --> 00:03:01,450 noch verstanden hat. Das ist so ein bisschen ein Problem, und das wird nochmal 39 00:03:01,450 --> 00:03:04,660 verstärkt dadurch, dass wir eben heute so eine Modularisierungs- und 40 00:03:04,660 --> 00:03:09,460 Abhängigkeitswelle haben, dass Leute einfach noch Module von anderswo mit 41 00:03:09,460 --> 00:03:16,540 reinziehen und sich einfach im Grunde ohne Grundlage in der Realität vorstellen, dass 42 00:03:16,540 --> 00:03:20,650 derjenige schon wissen wird, was er tut. Und so ist es eben häufig nicht, sondern 43 00:03:20,650 --> 00:03:25,480 das sind genau so Leute wie du und ich, die eben auch explorativ gearbeitet haben. 44 00:03:25,480 --> 00:03:30,070 Das kann man sich auch ganz gut selbst überlegen, wenn man so ein kurzes 45 00:03:30,070 --> 00:03:34,210 Gedankenexperiment macht. Das konnte man auch schon live beobachten. Also nehmen 46 00:03:34,210 --> 00:03:37,840 wir mal an, jemand findet einen Weg, um besser mit Komplexität umzugehen. Zum 47 00:03:37,840 --> 00:03:41,200 Beispiel Modularisierung oder objektorientierte Programmierung, als das 48 00:03:41,200 --> 00:03:44,770 gerade frisch war. Und dann würde man ja hoffen, dass wir die Software, die wir 49 00:03:44,770 --> 00:03:47,560 davor geschrieben haben, jetzt besser machen, weil wir das besser im Griff 50 00:03:47,560 --> 00:03:51,100 haben. Aber das passiert halt nicht, sondern was passiert ist, dass wir dann 51 00:03:51,100 --> 00:03:57,220 eben größere Software schreiben und wieder am Limit arbeiten. Ich glaube, dass das 52 00:03:57,220 --> 00:04:00,400 kein Problem der Softwareentwicklung oder des Programmierens ist, sondern generell 53 00:04:00,400 --> 00:04:03,790 ein Problem mit Menschen. So hat uns die Evolution gemacht, und da müssen wir 54 00:04:03,790 --> 00:04:07,820 lernen mit umzugehen. Und ich will das mal illustrieren: Ich habe so eine Theorie, 55 00:04:07,820 --> 00:04:14,870 die nenne ich die Gradienten-Theorie. Die These ist, dass Menschen ihre Umgebung wie 56 00:04:14,870 --> 00:04:18,110 ein Optimierungsverfahren betrachten in der Mathematik. Das heißt, man hat 57 00:04:18,110 --> 00:04:22,850 sozusagen ein Gelände und sucht den höchsten oder tiefsten Punkt - das ist so 58 00:04:22,850 --> 00:04:29,360 ein Optimierungsproblem. Und dabei geht man eben nicht gezielt vor, wenn man das 59 00:04:29,360 --> 00:04:34,280 Gelände nicht kennt, sondern man muss Annahmen treffen, und das kann man an sich 60 00:04:34,280 --> 00:04:37,490 selbst beobachten. Wenn es zu kalt ist, dann geht man ja zur Heizung und stellt 61 00:04:37,490 --> 00:04:41,510 nicht so ein, wie man es haben will, sondern man stellt heiß, und dann wartet 62 00:04:41,510 --> 00:04:44,390 man, bis es zu warm wird, und dann geht man wieder hin und stellt wieder runter. 63 00:04:44,390 --> 00:04:47,510 Das heißt, wir haben so ein Annäherungsverfahren, wie wir mit der Welt 64 00:04:47,510 --> 00:04:50,030 umgehen. Und das ist nicht nur bei Heizungen. Das ist auch beim Autofahren, 65 00:04:50,030 --> 00:04:53,840 wenn wir so eine Landkarte haben, dann gucken wir uns an, was ist denn das Limit? 66 00:04:53,840 --> 00:04:58,730 Wo müssen wir abbiegen? Und den Weg dahin ignorieren wir, obwohl der vielleicht ganz 67 00:04:58,730 --> 00:05:03,410 schön ist. Viele Sachen, die wir machen, auch die Geschwindigkeitsauswahl, ist so 68 00:05:03,410 --> 00:05:06,320 ein Gradienten-Ding Wir beschleunigen, bis wir uns unwohl fühlen. Dann gehen wir 69 00:05:06,320 --> 00:05:11,390 wieder ein bisschen zurück. Oder wenn man im Wörterbuch oder Telefonbuch 70 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 71 00:05:15,785 --> 00:05:19,070 weit ist, geht man wieder zurück. Also der elementare Teil ist jedenfalls: wir haben 72 00:05:19,070 --> 00:05:22,580 die Annahme, dass das Gelände ungefähr so aussieht. Wir haben hier eine glatte 73 00:05:22,580 --> 00:05:26,480 Übergänge, und dann funktioniert das Verfahren gut. Das heißt Gradient Descent 74 00:05:26,480 --> 00:05:29,930 übrigens, dass man versucht, der Schwerkraft hinterherzulaufen und den 75 00:05:29,930 --> 00:05:34,490 tiefsten Punkt zu suchen. Aber es funktioniert in zwei Fällen eben nicht 76 00:05:34,490 --> 00:05:38,090 gut: Der eine ist, wenn es einen Abhang gibt, über den ich rüberlaufe und dann 77 00:05:38,090 --> 00:05:41,930 kann ich nichts zurück korrigieren. Und das läuft auch nicht gut, wenn man nicht 78 00:05:41,930 --> 00:05:46,400 merkt, wenn man zu weit gegangen ist. Also ist so ähnlich wie der Abhang, und das 79 00:05:46,400 --> 00:05:49,970 zweite Problem ist, wenn man nicht zurückrollen kann, aus anderen Gründen. 80 00:05:49,970 --> 00:05:53,810 Die gibts in der Softwareentwicklung eben häufiger, und es stellt sich heraus, sind 81 00:05:53,810 --> 00:05:58,340 genau die Art von Problemen, die Menschen haben. Zum Beispiel, wenn wir so was haben 82 00:05:58,340 --> 00:06:03,430 wie zwei Wochen Probeabo, dann vergessen die Leute halt, da wieder auszutreten, 83 00:06:04,030 --> 00:06:09,580 oder Drogenabhängigkeit ist ein Klassiker, Spielesucht. Und in der 84 00:06:09,580 --> 00:06:12,370 Softwareentwicklung oder überhaupt im Projektmanagement ist es häufig: Jetzt 85 00:06:12,370 --> 00:06:17,260 haben wir schon so viel investiert, jetzt können wir nichts zurück. Security ist 86 00:06:17,260 --> 00:06:22,240 kein Gradient, es sieht vielleicht aus wie ein Gradient, aber es ist keiner. Das ist 87 00:06:22,240 --> 00:06:26,800 gerade, glaube ich, das Grundproblem von der IT-Security. Man merkt nicht, wenn man 88 00:06:26,800 --> 00:06:30,640 zu weit gegangen ist. Das merkt man erst, wenn man gehackt wird. Und dann kann man 89 00:06:30,640 --> 00:06:35,020 nicht mehr zurückrollen. Dann sind die Daten schon weg. Komplexität ist ähnlich 90 00:06:35,020 --> 00:06:38,260 wie Security auch kein Gradient, aber es fühlt sich an wie einer. Und das ist, 91 00:06:38,260 --> 00:06:42,130 glaube ich, der Grund, warum wir damit so schlecht umgehen können. Das fühlt sich 92 00:06:42,130 --> 00:06:45,130 an, als würden wir alles unter Kontrolle haben. Und zu dem Zeitpunkt, wo wir 93 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 94 00:06:50,140 --> 00:06:54,820 Daten rausgeben so an Facebook oder so ist genauso ein Pseudo-Gradient, nenne ich das 95 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. 96 00:07:00,550 --> 00:07:05,650 So die Schlussfolgerung ist eigentlich: Komplexität ist böse. Wir bemerken sie zu 97 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 98 00:07:09,610 --> 00:07:14,680 gegensteuern. Die Kosten dafür werden im Moment an unsere Kunden, wenn wir das 99 00:07:14,680 --> 00:07:19,480 beruflich machen, externalisiert, an unsere Benutzer und an unser zukünftiges 100 00:07:19,480 --> 00:07:24,700 Selbst. Daher findet man relativ selten glückliche ältere Softwareentwickler. 101 00:07:24,700 --> 00:07:28,901 *Publikum lacht* So, das war der erste Gedankengang, der 102 00:07:28,901 --> 00:07:32,786 mich in die Richtung geführt hat. Der zweite Gedankengang: Ich will jetzt mal 103 00:07:32,786 --> 00:07:35,854 das GNU Manifesto herausgreifen. Stellvertretend. Das ist kein GNU-Bashing 104 00:07:35,854 --> 00:07:39,484 hier, aber am GNU Manifesto kann man das ganz gut zeigen. Das war die ursprüngliche 105 00:07:39,484 --> 00:07:43,647 Ankündigung des GNU-Projekts von Richard Stallman. Da hat er geschrieben: "Wir 106 00:07:43,647 --> 00:07:47,939 machen Unix-Programme, und wir werden aber nicht genau dasselbe sein wie Unix. We 107 00:07:47,939 --> 00:07:53,041 will make all improvements that are convenient." Das ist ein ganz furchtbarer 108 00:07:53,041 --> 00:07:58,473 Satz. Was heißt denn 'convenient', für wen denn? Aber das ist genau die 109 00:07:58,473 --> 00:08:03,258 Herangehensweise, die viele Leute haben, die Software schreiben: "Oh, das können 110 00:08:03,258 --> 00:08:07,281 wir noch schnell dazutun." Was fehlt, ist so ein Korrektiv, dass man vorher drüber 111 00:08:07,281 --> 00:08:11,304 nachdenkt: "Was hänge ich mir eigentlich gerade für eine Legacy ans Bein?" Ich 112 00:08:11,304 --> 00:08:15,766 glaube dieser Convenience-Gedanke beim Erweitern von Software ist unsere Erbsünde 113 00:08:15,766 --> 00:08:20,010 - um hier mal ein bisschen katholisch zu werden - in der Softwareentwicklung. Die 114 00:08:20,010 --> 00:08:24,252 haben alle schon einmal begangen und das kriegt man eben nicht nachkorrigiert. 115 00:08:24,252 --> 00:08:27,256 Daher ist der einzige Weg, das loszuwerden, wenn man die ganze 116 00:08:27,256 --> 00:08:31,626 Software oder das ganze Modul wegschmeißt und neu macht. Aber Software stirbt halt 117 00:08:31,626 --> 00:08:36,592 nicht. Ich habe im Umgang mit Software erst verstanden, dass es gut ist, dass 118 00:08:36,592 --> 00:08:40,508 Menschen sterben, weil das ist ein Korrektiv, was gebraucht wird. Wenn System 119 00:08:40,508 --> 00:08:44,026 besser werden soll, dann muss der alte Scheiß auch irgendwann sterben können. Und 120 00:08:44,026 --> 00:08:49,584 das passiert bei Software halt nicht. Es ist ein Feature, dass Dinge nicht ewig 121 00:08:49,584 --> 00:08:55,269 halten. Man kann das allgemein beobachten, wenn jemand seine Software erweitern will 122 00:08:55,269 --> 00:08:58,484 und er hat die Wahl zwischen "Wir machen jetzt hier mal was, um das konkrete 123 00:08:58,484 --> 00:09:01,905 Problem zu lösen" oder "Wir machen hier was, um ein allgemeineres Problem zu 124 00:09:01,905 --> 00:09:06,636 lösen." Dann werden die Leute immer das allgemeinere Problem zu lösen versuchen. 125 00:09:06,636 --> 00:09:12,057 Viel Feind, viel Ehr. Und das kann man fast flächendeckend beobachten. Es gibt 126 00:09:12,057 --> 00:09:16,859 sehr wenige Ausnahmen davon. Und ich hatte meinen Aha-Moment, als ich eines Tages mal 127 00:09:16,859 --> 00:09:21,215 gdb aufgerufen habe auf ein Projekt, also ich habe jetzt hier /tmp genommen, aber 128 00:09:21,215 --> 00:09:26,135 das Projekt war irgendein Checkout. Ich habe in meinem eigenen Webserver 129 00:09:26,135 --> 00:09:30,507 einen .gdbinit. Das ist eine Konfig-Datei für den GNU-Debuger, wo man zum Beispiel 130 00:09:30,507 --> 00:09:33,405 sagen kann: "Ruf das Programm, wenn ich es debuggen will, mit diesen 131 00:09:33,405 --> 00:09:36,808 Kommandozeilenargumenten auf!" Und da schreibe ich dann rein: "Nimm nicht Port 132 00:09:36,808 --> 00:09:41,393 80, weil das klappt nicht, sondern nimm Port irgendwie 8005 oder so, was-weiß-ich, 133 00:09:41,393 --> 00:09:46,097 halt localhost zum debuggen." Und gdb hat eines Tages angefangen zu sagen: "Nee, die 134 00:09:46,097 --> 00:09:50,553 .gdbinit-Datei, die nehme ich aber nicht, denn die liegt hier in einem Verzeichnis, 135 00:09:50,553 --> 00:09:56,000 was du nicht freigeschaltet hast." Und das war genau so ein Versuch, diesen Fehler 136 00:09:56,000 --> 00:10:01,097 nach Werk, nach der Tat zu korrigieren. gdb hat festgestellt: "Unsere Konfig-Datei 137 00:10:01,097 --> 00:10:05,810 ist so mächtig geworden, dass es ein Sicherheitsproblem darstellt", und hat dann 138 00:10:05,810 --> 00:10:11,038 halt die ganze Konfig-Sache zugenagelt für rückblickend. Und das hat halt mehr 139 00:10:11,038 --> 00:10:15,686 kaputtgemacht, als nötig gewesen wäre - vielleicht, weiß ich nicht - aber es war 140 00:10:15,686 --> 00:10:19,270 für mich sehr ärgerlich. Man kann hier so einen Autopfad eintragen, aber da ist mir 141 00:10:19,270 --> 00:10:22,218 das halt zum ersten Mal so richtig aufgefallen. Das war jetzt vor ein paar 142 00:10:22,218 --> 00:10:25,942 Jahren. Ich weiß gar nicht, wann das genau war. Es gab so einen ähnlichen Fall 143 00:10:25,942 --> 00:10:30,041 nochmal: mit vim, dem Editor, den ich immer benutze. Da kann man nämlich so 144 00:10:30,041 --> 00:10:33,882 Sachen machen wie in einem Kommentar in der zu editierenden Datei in den ersten 145 00:10:33,882 --> 00:10:37,028 drei Zeilen oder in den letzten drei Zeilen kann man so ein paar Konfig- 146 00:10:37,028 --> 00:10:41,870 Settings ändern. Das ist gedacht, um zu sagen: "Ich benutz' hier in Tabstop von 4 oder 147 00:10:41,870 --> 00:10:46,160 so." Aber der Parser dafür hat ein Sicherheitsproblem gehabt, und damit war 148 00:10:46,160 --> 00:10:50,512 es dann möglich, sozusagen eine Datei zu erzeugen, die ein Programm ausgeführt hat, 149 00:10:50,512 --> 00:10:55,564 wenn sie in vim geöffnet wurde, was natürlich nicht gewollt war. Aber es ist 150 00:10:55,564 --> 00:10:59,847 dasselbe Problem in grün. Und ich glaube, das Problem kann man ein bisschen 151 00:10:59,847 --> 00:11:03,135 verallgemeinern, nachdem ich gerade gegen Verallgemeinern gewettert habe, aber in 152 00:11:03,135 --> 00:11:06,535 der Betrachtung ist Verallgemeinern ja gut, in der Software eher schlecht. Ich 153 00:11:06,535 --> 00:11:10,777 will das mal ein Beispiel illustrieren. Nehmen wir an, wir haben eine CSV-Datei 154 00:11:10,777 --> 00:11:16,194 mit irgendwie Trouble-Tickets. Feld 4 ist das, an dem wir jetzt Interesse haben. 155 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 156 00:11:21,511 --> 00:11:26,285 der vierten Felder haben. Dann mache ich als erstes mal cut, wir sind halt unter 157 00:11:26,285 --> 00:11:31,012 Unix. Der filtert es hier raus, die erste Zeile muss noch weg, also mach ich 158 00:11:31,012 --> 00:11:34,193 hier noch einen tail. Dann ist die erste Zeile weg, jetzt muss ich noch eine 159 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 160 00:11:37,746 --> 00:11:43,442 Unix. Und dann muss ich das ausrechnen. So! Aber was ist denn, wenn da jetzt nicht 161 00:11:43,442 --> 00:11:49,381 1 stand, sondern fred? Dann können wir feststellen: cut hat damit kein Problem, 162 00:11:49,381 --> 00:11:54,442 tail hat damit kein Problem, paste hat damit kein Problem, aber bc fällt auf die 163 00:11:54,442 --> 00:12:01,973 Fresse. So, das heißt, schlimmer noch: bc ist programmierbar. Da könnte jetzt zum 164 00:12:01,973 --> 00:12:05,214 Beispiel die Ackermann-Funktion stehen und dann steht der Rechner für eine Stunde, 165 00:12:05,214 --> 00:12:09,772 während er versucht, irgendeine Rekursion aufzulösen. Und ich glaube, das ist 166 00:12:09,772 --> 00:12:14,823 sinnvoll, hier ein Konzept einzuführen und zu sagen: cut, tail und paste sind 167 00:12:14,823 --> 00:12:18,817 harmlos, bc nicht. Das war so einer der Gedanken, wo ich dachte: "Okay, da kann 168 00:12:18,817 --> 00:12:22,152 man eigentlich mal ein Vortrag drüber machen." Allerdings ist es nicht 169 00:12:22,152 --> 00:12:27,235 hinreichend. Es gibt verschiedene Arten von Harmlosigkeit. Aber ich glaube, die 170 00:12:27,235 --> 00:12:31,405 Unterscheidung ist schon mal hilfreich. Ja, sagen wir mal, versuchen wir es einmal 171 00:12:31,405 --> 00:12:35,204 zu formulieren: Software ist harmlos, wenn unerwartete Eingaben kein unerwartetes 172 00:12:35,204 --> 00:12:38,868 Verhalten oder unerwartete Arten von Ausgabe erzeugen. Zum Beispiel, so eine 173 00:12:38,868 --> 00:12:43,166 SHA-Checksumme ist immer harmlos: Egal, was ich dafür Daten rein tue, die 174 00:12:43,166 --> 00:12:47,742 Ausgabe hat ein bekanntes Format. Oder word count (wc) ist auch so ein Ding. 175 00:12:47,742 --> 00:12:52,104 Jetzt könnte man sagen: "Okay, nimm doch noch awk!" Und in awk habe ich zum 176 00:12:52,104 --> 00:12:55,955 Beispiel kein Problem, wenn da jetzt fred steht statt 4 und der Interpreter 177 00:12:55,955 --> 00:13:00,541 interpretiert ja auch nicht Funktionen. Das sieht besser aus, aber es ist auch 178 00:13:00,541 --> 00:13:05,397 harmlos, und es stellt sich heraus: awk ist eine andere Art von nicht harmlos, 179 00:13:05,397 --> 00:13:09,385 denn man kann im Code im Dateisystem rumschreiben. Da muss ich jetzt nicht auf 180 00:13:09,385 --> 00:13:13,548 die Eingabe achten. Aber ich muss auf die andere Eingabe achten, nämlich den Code, 181 00:13:13,548 --> 00:13:17,275 den ich auf der Kommandozeile übergebe. Und da kann man eigentlich auch sagen, 182 00:13:17,275 --> 00:13:21,812 dass man die Unterscheidung haben möchte. Das ist in der Industrie übrigens ein 183 00:13:21,812 --> 00:13:25,862 großes Problem: Die Spieleindustrie ist dazu übergegangen, in großem Stil 184 00:13:25,862 --> 00:13:30,856 irgendwelche Interpreter in ihre Spiele einzubauen, um die Business-Logik, also 185 00:13:30,856 --> 00:13:36,820 nicht die AI, sondern so kleine Skripte in einer Skriptsprache machen zu können und 186 00:13:36,820 --> 00:13:41,132 einer der beliebtesten Skript-Interpreter dafür ist Lua. Und Lua wird vor allem 187 00:13:41,132 --> 00:13:45,091 deswegen genommen, weil der halt nix kann, was man nicht freischaltet. Also der kann 188 00:13:45,091 --> 00:13:48,926 nicht Datei öffnen, kann keine Sockets aufmachen. Das kann man alles nachreichen, 189 00:13:48,926 --> 00:13:53,190 und dann hat man natürlich wieder ein Problem. Aber das ist ein reales Problem. 190 00:13:53,190 --> 00:13:57,149 Viele Open-Source-Leute denken da nicht drüber nach, weil sie sich denken: "Ach, 191 00:13:57,149 --> 00:14:00,358 ich liefer das aus und der Rest ist ja nicht mehr mein Problem." Aber ich finde, 192 00:14:00,358 --> 00:14:03,335 da müssen wir mal generell drüber nachdenken, und zwar am besten vor dem 193 00:14:03,335 --> 00:14:06,771 Ausliefern, am besten schon beim Programmieren. Also das ist eine andere 194 00:14:06,771 --> 00:14:11,226 Art von Harmlosigkeit. Vorher war die Harmlosigkeit: "Kann eine böse Eingabe böse 195 00:14:11,226 --> 00:14:15,014 Ergebnisse erzielen?" Und jetzt ist: "Kann das Programm selbst böse Dinge machen?" 196 00:14:15,014 --> 00:14:19,322 Und das ist eigentlich eine sehr moderne Überlegung, weil wir heutzutage viel mit 197 00:14:19,322 --> 00:14:23,874 Sandboxing arbeiten. Da geht es genau darum, zu verhindern, dass ein Programm 198 00:14:23,874 --> 00:14:28,024 versehentlich oder absichtlich böse Dinge tut. Und da gibt's wieder auch verschiedene 199 00:14:28,024 --> 00:14:32,605 Sachen, die ein Programm anstellen kann. bc konnte Rechenzeit verbraten. awk kann 200 00:14:32,605 --> 00:14:37,095 im Dateisystem lesen und schreiben, und das geht natürlich weiter. Kommen wir 201 00:14:37,095 --> 00:14:41,740 zurück zum GNU Manifesto: GNU awk ist eine spezielle Version von awk und die kann 202 00:14:41,740 --> 00:14:45,652 Sockets aufmachen, völlig ohne Not. Das heißt, wenn wir einfach awk benutzen und 203 00:14:45,652 --> 00:14:49,086 denken, ach awk kann im Dateisystem schreiben, aber das hab ich read-only 204 00:14:49,086 --> 00:14:53,457 gemountet, da passiert schon nichts. Dann ist aber GNU awk im Einsatz, ist es halt 205 00:14:53,457 --> 00:14:57,802 doch wieder nicht harmlos. Bash kann übrigens auch Sockets aufmachen! Ich weiß 206 00:14:57,802 --> 00:15:02,788 nicht, wie viele Leute das wussten? Gut, die Sache geht natürlich noch weiter: Nach 207 00:15:02,788 --> 00:15:06,446 awk kam Perl. Das ist noch viel schlimmer und Perl kann eval(), das ist so das 208 00:15:06,446 --> 00:15:11,425 schlimmste Übel, was man haben kann in einer Programmiersprache aus meiner Sicht. Ein 209 00:15:11,425 --> 00:15:15,985 bisschen näher am Endkunden kann man das auch an Browsern betrachten. Also gucken 210 00:15:15,985 --> 00:15:20,523 wir uns zum Beispiel mal Netscape an: Netscape hat auch mehrfach die Wahl gehabt 211 00:15:20,523 --> 00:15:24,977 zwischen nützlich und harmlos und hat immer nützlich gewählt. Es ging dann los 212 00:15:24,977 --> 00:15:29,442 mit den Plugins. Weiß nicht, wer sich hier noch an das Flash-Plugin erinnert, oder 213 00:15:29,442 --> 00:15:33,755 vorher hatten wir alle den RealPlayer und das [Adobe] Acrobat-Plugin gab es auch 214 00:15:33,755 --> 00:15:37,641 mal - und das war alles scheiße, weil diese Plugins Native Code waren: die 215 00:15:37,641 --> 00:15:41,829 konnten alles tun, was das Betriebssystem ihnen erlaubt. Das heißt, das war zwar 216 00:15:41,829 --> 00:15:45,635 sehr nützlich, aber es war eben auch sehr gefährlich. Und das war eine bewusste 217 00:15:45,635 --> 00:15:49,579 Entscheidung von den Browsern, das zuzulassen. Das eigentliche Ziel von 218 00:15:49,579 --> 00:15:54,202 diesem Vortrag ist, den Programmierern unter euch so ein bisschen das Bewusstsein 219 00:15:54,202 --> 00:15:58,933 dafür zu geben, dass man nicht einfach eine Plugin-Schnittstelle einbaut, die 220 00:15:58,933 --> 00:16:04,564 alles kann. Die nächste Iteration war: Wir machen einfach alles in JavaScript. Das 221 00:16:04,564 --> 00:16:09,562 war, sah erst mal besser aus, aber dieser JavaScript lief dann auch mit genügend 222 00:16:09,562 --> 00:16:13,861 Rechten, um im System Mist anzustellen und zumindest im Browser Mist anzustellen. Da 223 00:16:13,861 --> 00:16:17,610 stellt sich heraus: Die Leute haben ihre wichtigen Daten heutzutage im Browser, 224 00:16:17,610 --> 00:16:21,064 weil sie Onlinebanking machen. Und das reicht, um richtig doll Schaden 225 00:16:21,064 --> 00:16:25,609 anzustellen. Da musste auch nachkorrigiert werden. Chrome limitiert jetzt noch weiter 226 00:16:25,609 --> 00:16:29,383 aus Sicherheitsgründen, um den Adblocker kaputtmachen zu können. Das ist eigentlich 227 00:16:29,383 --> 00:16:32,601 immer dieselbe Falle, in die wir hier reinlaufen. Ich weiß nicht, wer hier 228 00:16:32,601 --> 00:16:37,285 Windows benutzt? Unter Windows gibt es ein Tool, das von Mark Russinovich - der hat 229 00:16:37,285 --> 00:16:41,300 sich inzwischen kaufen lassen von Microsoft, ist jetzt also ein offizielles 230 00:16:41,300 --> 00:16:44,680 Microsoft-Tool. Und die einzige Funktion von dem Tool ist, die verschiedenen 231 00:16:44,680 --> 00:16:48,013 Plugins zu listen, die im System eingetragen sind. Und ich habe hier mal 232 00:16:48,013 --> 00:16:52,285 ein relativ sauberes System genommen. Es geht jetzt nicht um das hier unten oder 233 00:16:52,285 --> 00:16:56,549 die Größe von dem Scrollbalken, sondern einfach, wie viele Tabs es oben gibt: Das 234 00:16:56,549 --> 00:17:00,745 sind alles Möglichkeiten, wie sich Plugins im System einnisten können, und das hat 235 00:17:00,745 --> 00:17:04,445 einfach niemand mehr im Blick, weil einfach immer in die falsche Richtung 236 00:17:04,445 --> 00:17:08,798 entschieden wurde. Also, das ist, glaube ich, ein Kernproblem. Es gab noch eine 237 00:17:08,798 --> 00:17:13,857 dritte Herleitung: Mein Security-Alltag besteht darin, dass sich Firmen gehe und 238 00:17:13,857 --> 00:17:17,926 zeigen mir ihren Quellcode und dann suche ich nach Bugs. Und dann sage ich denen, 239 00:17:17,926 --> 00:17:21,920 welche Bugs ich gefunden habe. Und da gibts dann halt gelegentlich so Fälle, wo 240 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, 241 00:17:25,808 --> 00:17:30,035 sondern die haben schon eine eigene Datenbank, einen Bugtracker, und da sind 242 00:17:30,035 --> 00:17:34,955 schon siebenstellig Bugs drin. Ja, sowas kommt vor. Und weil das so ein Problem 243 00:17:34,955 --> 00:17:39,361 ist, dass wir so viele Bugs haben, gibt's jetzt Gegenstrategien von den Entwicklern, 244 00:17:39,361 --> 00:17:42,746 die dann anfangen zu sagen: "Okay, wenn der Bug nicht wichtig ist, dann kann ich 245 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. 246 00:17:46,830 --> 00:17:52,134 Ich versuche seit einer Weile, den Begriff Bug-Welle dafür zu etablieren, die man 247 00:17:52,134 --> 00:17:58,087 vor sich herschiebt als großer Dampfer. Aber Bugtracker sind in der Realität da 248 00:17:58,087 --> 00:18:03,812 draußen häufig riesige Daten-Endlager: Ich habe zum Beispiel neulich einen Bug 249 00:18:03,812 --> 00:18:08,146 bei Firefox gemeldet und habe die ID 1.590.000 gekriegt. Das ist ja schon 250 00:18:08,146 --> 00:18:11,876 ein schlechtes Zeichen, eigentlich. Aber es ist ein gutes Zeichen, weil der 251 00:18:11,876 --> 00:18:16,007 Bugtracker offen ist. Bei Microsoft kann man das gar nicht sehen, wie viel Bugs die 252 00:18:16,007 --> 00:18:19,501 haben. Das ist jetzt hier nur als Illustration gemeint. Mozilla ist nicht 253 00:18:19,501 --> 00:18:23,170 besonders scheiße. Mozilla hat nur einen offenen Tracker, an dem ich das schön 254 00:18:23,170 --> 00:18:27,217 etablieren kann. Was ich jetzt noch zeigen wollte - ich hab noch mal geguckt: "Was ist 255 00:18:27,217 --> 00:18:31,017 denn der erste Bug, den ich da gefiled habe?" Der hatte noch eine sechsstellige 256 00:18:31,017 --> 00:18:37,953 ID. Das war 2003. Wenn man sich den Verlauf anguckt, der Bugnummern, dann 257 00:18:37,953 --> 00:18:43,047 stellt man fest: Das wächst exponentiell. Und es ist nicht so, dass die Bugs dann 258 00:18:43,047 --> 00:18:48,431 irgendwie irgendwann weggehen von irgendwann. Ich habe zwei große Ereignisse 259 00:18:48,431 --> 00:18:52,235 beobachtet, bei denen Bugs geschlossen werden: Das ist, wenn es ein neues Release 260 00:18:52,235 --> 00:18:55,851 gibt, und da schmeißt man die alte JavaScript-Engine raus und macht eine neue 261 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 262 00:18:59,700 --> 00:19:03,568 wenn man was geschafft hat. Und der andere Weg ist dieser hier: Ich weiß nicht, 263 00:19:03,568 --> 00:19:06,848 ob man das hinten lesen kann? Mozilla hat einfach einen Bug von mir geschlossen. Da 264 00:19:06,848 --> 00:19:10,034 steht drin: "This bug has been automatically resolved after a period of 265 00:19:10,034 --> 00:19:14,008 inactivity". Die war jetzt nicht von mir, die Inactivity. Ich hab den Bug gefiled, 266 00:19:14,008 --> 00:19:17,750 und bei Mozilla hat sich keiner drum gekümmert. Und dann haben die den halt 267 00:19:17,750 --> 00:19:21,355 automatisch geschlossen, weil die Statistik so schlecht aussah. Das ist ein 268 00:19:21,355 --> 00:19:24,378 Riesenproblem, nicht nur bei Mozilla. Wie gesagt, das ist hier nur der 269 00:19:24,378 --> 00:19:28,262 Blitzableiter, den ich zeigen kann, weil es alles öffentlich ist bei denen. Aber 270 00:19:28,262 --> 00:19:32,349 das führt zu so einer Kaskade aus Verhalten und Gegenverhalten. Zum Beispiel 271 00:19:32,349 --> 00:19:36,089 sieht man dann: unwichtige Bugs werden halt gar nicht gefixt. Und dann schreiben 272 00:19:36,089 --> 00:19:39,461 die Leute halt "wichtig" an ihre Bugs, wenn sie wollen, dass die gefixt werden. 273 00:19:39,461 --> 00:19:42,780 Und da haben die Leute gesagt: "Okay, die wichtigen Bugs bleiben dann 274 00:19:42,780 --> 00:19:46,849 auch liegen, weil da gibt's zu viele von." Und dann schreiben die Leute 275 00:19:46,849 --> 00:19:51,472 "Security" an ihre Bugs ran, und dann haben wir jetzt eine Welle von Security- 276 00:19:51,472 --> 00:19:56,008 Bugs, und da wird dann verhandelt: "Ist das denn wirklich ein Problem?" Und da kommen 277 00:19:56,008 --> 00:20:01,232 dann so Ausreden, wie: "Ist ja nur ein Crash." Und der Punkt daran ist, dass es 278 00:20:01,232 --> 00:20:07,589 hier eine unheilige Allianz gibt mit einem anderen Trend, nämlich, dass Firmen 279 00:20:07,589 --> 00:20:11,476 einfach sehen: sie haben so viele Bugs offen, dass es gar nicht das Ziel ist, sie 280 00:20:11,476 --> 00:20:15,295 alle loszuwerden. Es gibt einfach zu viele, das ist unrealistisch. Stattdessen 281 00:20:15,295 --> 00:20:19,598 führt man Metriken ein, wie dass man Fuzzing macht. Fuzzing ist 282 00:20:19,598 --> 00:20:23,897 eigentlich keine doofe Idee, aber es ist eben nicht: "alle Bugs finden", sondern es 283 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 284 00:20:28,090 --> 00:20:33,011 Metrik, die da rausfällt. Wir haben so und so viel Fuzz-Testcases gemacht, und jetzt... 285 00:20:33,011 --> 00:20:37,402 Sind wir jetzt besser oder schlechter als vorher? Ist alles schwer zu sagen. 286 00:20:37,402 --> 00:20:41,769 Dann gibt es Bug Bounties, was ich persönlich für Bullshit halte. Das macht 287 00:20:41,769 --> 00:20:46,975 man, damit die PR-Abteilungen zeigen kann: "Guck mal, so viel wert sind Bugs bei uns, 288 00:20:46,975 --> 00:20:51,635 weil wir so wenig Bugs haben." Das ist die Idee. Und der Rest der Industrie hat 289 00:20:51,635 --> 00:20:55,373 einfach Mitigations gemacht. Da haben Sie dann gesagt: "Okay, wir schließen die Bugs 290 00:20:55,373 --> 00:20:58,367 nicht mehr, wir machen das Exploiten schwieriger." Und das funktioniert. Ich 291 00:20:58,367 --> 00:21:01,752 bin da immer dagegen gewesen. Ich musste also jetzt meinen Hut fressen, sozusagen. 292 00:21:01,752 --> 00:21:05,930 Das funktioniert. Aber es hat halt Nebeneffekte. Ich weiß nicht, ob ich Zeit 293 00:21:05,930 --> 00:21:09,778 habe für Anekdoten. Ich bin nämlich zeitlich sehr knapp dran. Aber ich hab mal 294 00:21:09,778 --> 00:21:13,974 den Typ getroffen, der die Internet- Explorer-Bugs verwaltet, die reinkommen, 295 00:21:13,974 --> 00:21:18,438 und ich habe den getroffen, weil ich 50 Bugs gefiled habe. Und er hat gesagt "35 296 00:21:18,438 --> 00:21:20,345 kenne ich schon". *Publikum lacht* 297 00:21:20,345 --> 00:21:23,400 Und da hab ich gesagt: "Wie jetzt?" Der 298 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. 299 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, 300 00:21:33,658 --> 00:21:37,336 irgendwelche zu schließen, wir verwalten die nur noch." Das war der Stand 301 00:21:37,336 --> 00:21:41,931 damals. Das ist inzwischen besser geworden. Also Microsoft. Und wie gesagt, 302 00:21:41,931 --> 00:21:47,848 das sind hier Beispiele, das ist in anderen Firmen ähnlich. Man verwaltet die 303 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 304 00:21:51,779 --> 00:21:55,288 Jahre gar nicht drüber reden dürfen. Aber inzwischen haben sie das selbst 305 00:21:55,288 --> 00:21:58,910 veröffentlicht. Deswegen darf ich das jetzt doch erzählen. Da haben sie halt 306 00:21:58,910 --> 00:22:03,159 festgestellt Wir haben lauter Memory Corruption Bugs, weil wir immer die Sachen 307 00:22:03,159 --> 00:22:07,913 vom Heap free()n und dann aber noch benutzen. Da haben Sie jetzt einen Hack 308 00:22:07,913 --> 00:22:12,536 gebaut, der die Sachen dann halt nicht free()t, sondern in eine Liste tut. Und 309 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 310 00:22:17,253 --> 00:22:21,690 gibt die dann nicht frei. Das ist ein furchtbarer Hack. Wär' mir ja zu peinlich 311 00:22:21,690 --> 00:22:26,237 gewesen, das irgendwo zu erwähnen. Aber Microsoft macht jetzt PR damit, wie geil 312 00:22:26,237 --> 00:22:30,208 memgc ist. Und die Chrome-Leute haben sich das angesehen haben und gesagt: 313 00:22:30,208 --> 00:22:33,999 "Boah, das ist ja geil." *Publikum lacht* 314 00:22:33,999 --> 00:22:36,695 Das ist der Stand, wie die Industrie 315 00:22:36,695 --> 00:22:41,009 funktioniert. Das Problem ist jetzt aber, dass Bugs nur noch mit Exploit als 316 00:22:41,009 --> 00:22:45,459 Security-Problem anerkannt werden. Also das ist nicht branchenübergreifend, aber 317 00:22:45,459 --> 00:22:49,214 es ist bei vielen inzwischen so: Wenn man keinen Exploit liefert, wird es nicht 318 00:22:49,214 --> 00:22:52,446 anerkannt. Aber wir haben ja vorhin gesehen, dass überhaupt nur noch 319 00:22:52,446 --> 00:22:56,310 anerkannte Security-Bugs gefixt werden. Das heißt, Bugs liegen einfach herum, weil 320 00:22:56,310 --> 00:23:00,526 der Nachweis nicht erbracht werden konnte. Und wenn das Ausnutzen von einem Bug durch 321 00:23:00,526 --> 00:23:04,246 die Mitigations schwieriger wird, heißt das eben, dass immer mehr tatsächliche 322 00:23:04,246 --> 00:23:07,796 Sicherheitsprobleme rumliegen, weil niemand Bock hat, den Nachweis zu 323 00:23:07,796 --> 00:23:12,318 erbringen, dass es ein Problem war. Das heißt nicht, dass keiner von den Bugs 324 00:23:12,318 --> 00:23:16,240 jemals geschlossen wird. Denn es stellt sich heraus: Die Entwickler haben so etwas 325 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 326 00:23:20,475 --> 00:23:24,298 Genua gebaut hat. Das heißt, die Leute laufen schon rum und schließen Bugs. Aber 327 00:23:24,298 --> 00:23:27,676 sie möchten halt nicht gezwungen werden dazu. Und sie möchten auch nicht 328 00:23:27,676 --> 00:23:31,460 anerkennen, dass es ein Problem war. Und das hat so eine Kaskade an Problemen in 329 00:23:31,460 --> 00:23:36,410 der Realität. Aber ich schließe daraus: Erst mal reaktiv auf das Problem mit den 330 00:23:36,410 --> 00:23:41,173 Bugs und der Softwarequalität zuzugehen, hilft eigentlich nicht. Ich sage das schon 331 00:23:41,173 --> 00:23:45,020 länger über Viren und Würmer und die Antiviren, die ich immer als Schlangenöl 332 00:23:45,020 --> 00:23:48,800 bezeichne. Ich glaube, dass das bei Bugs auch so ist: Viel zu viel Software wird 333 00:23:48,800 --> 00:23:53,213 einfach entwickelt, und man denkt sich: "Ach naja, dann können wir das mal ausliefern, 334 00:23:53,213 --> 00:23:57,578 und der Kunde testet das dann. Und dann melden die schon die Bugs und die fixen 335 00:23:57,578 --> 00:24:03,977 wir dann halt." Es gibt so inzwischen das geflügelte Wort: Man liefert aus, wenn der 336 00:24:03,977 --> 00:24:10,106 Updater funktioniert. Und da muss man ja irgendwie mit umgehen als Industrie. Ich 337 00:24:10,106 --> 00:24:13,625 versuche hier als Zielgruppe jetzt die Entwickler. Was machen wir denn jetzt? Das 338 00:24:13,625 --> 00:24:17,247 ist jetzt so die Frage. Und da gibt es natürlich verschiedene Ideen: Der FDP- 339 00:24:17,247 --> 00:24:21,130 Ansatz ist meines Erachtens gescheitert. Der Markt hat ja gar nichts geregelt. Die 340 00:24:21,130 --> 00:24:24,965 Leute kaufen immer noch alle irgendwie Windows und macOS. Das funktioniert, 341 00:24:24,965 --> 00:24:28,860 glaube ich, nicht. Dann kann man versuchen, an die Moral zu appellieren. 342 00:24:28,860 --> 00:24:33,035 Freiwillige Selbstkontrolle? Das funktioniert auch nicht aus meiner Sicht. 343 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 344 00:24:37,879 --> 00:24:42,818 funktioniert leider auch nicht. Und es gibt den Twitter-Ansatz: Ausgrenzung 345 00:24:42,818 --> 00:24:48,100 und mit Dingen drohen. Heugabelmobs. Das hat in meiner Beobachtung eher zu 346 00:24:48,100 --> 00:24:52,500 Abandonware geführt, weil die Leute halt weggerannt sind, und gesagt haben: 347 00:24:52,500 --> 00:24:56,206 "Das ist mir doch egal. Das ist nicht mehr meine Software." Es gibt auch einen 348 00:24:56,206 --> 00:24:59,868 Hybridansatz, den die katholische Kirche seit vielen Jahren erfolgreich fährt. 349 00:24:59,868 --> 00:25:03,716 Vielleicht ist das die Lösung. Dass man sagt: "Nicht der Markt, aber Sankt Peter 350 00:25:03,716 --> 00:25:08,630 regelt das." Und an Moral appellieren funktioniert so ein bisschen. Das müssen 351 00:25:08,630 --> 00:25:13,261 wir vielleicht ausbauen. Und dann dachte ich mir: "Was machen wir jetzt konkret?" Ich 352 00:25:13,261 --> 00:25:16,930 habe als erstes gedacht: "Wir müssen vielleicht gucken, ob wir die explorative 353 00:25:16,930 --> 00:25:19,907 Softwareentwicklung von der zielorientierten Softwareentwicklung 354 00:25:19,907 --> 00:25:23,917 trennen." Dass wir sagen, es ist gut und richtig, dass die Leute explorativ lernen. 355 00:25:23,917 --> 00:25:27,947 Aber das ist dann nicht das Produkt, was du shippst. Da müssen wir irgendwie 356 00:25:27,947 --> 00:25:31,971 hinkommen. Und ich appelliere seit Jahren an die Firmen und sage: "Gebt den Leuten 357 00:25:31,971 --> 00:25:35,440 Zeit, dass sie ein bisschen rumspielen und Sachen lernen können!" Denn sonst lernen 358 00:25:35,440 --> 00:25:39,425 sie das während der Produktentwicklung und dann wird das Produkt halt scheiße. Aber 359 00:25:39,425 --> 00:25:44,229 da kann ich so lange reden, bis ich blau anlaufe. Der Effekt ist bisher nicht 360 00:25:44,229 --> 00:25:48,829 vorzeigbar. Ich finde, man kann das gut auf den Punkt bringen, wenn man sagt: 361 00:25:48,829 --> 00:25:52,582 "Sei innovativ damit, was du tust, und nicht, wie du es tust." Eine Firma soll ja 362 00:25:52,582 --> 00:25:57,265 innovativ sein, soll Dinge probieren, neue Produkte machen, aber dann nicht 363 00:25:57,265 --> 00:26:02,796 irgendeine Experimental-Datenbank-Tech anwenden, die dann irgendwie mit den Daten 364 00:26:02,796 --> 00:26:08,344 verloren geht, weil - war noch nicht fertig. Ich glaube, es gibt da nicht nur 365 00:26:08,344 --> 00:26:13,337 eine Ursache, sondern es gibt mehrere Komponenten und die muss man auch getrennt 366 00:26:13,337 --> 00:26:16,676 betrachten. Die erste ist Unwissenheit. "Ich weiß einfach nicht, dass der Code 367 00:26:16,676 --> 00:26:19,707 scheiße war, den ich da importiert habe." Oder "Ich wusste nicht, wie man es besser 368 00:26:19,707 --> 00:26:23,220 macht, deswegen habe ich es halt nicht gut gemacht." Und dann gibt's, was ich mal 369 00:26:23,220 --> 00:26:26,838 absichtliche Unwissenheit nenne: "Wir haben keine guten Leute gefunden." Das 370 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. 371 00:26:30,901 --> 00:26:34,758 Solange das Projekt irgendwie so ein bisschen was an sich hat, was man 372 00:26:34,758 --> 00:26:38,616 vielleicht mal ausprobieren möchte. Das halte ich für eine Ausrede. Ich glaube, 373 00:26:38,616 --> 00:26:42,095 das sagen Leute, die sagen: "Ach, es ging halt nicht anders, wir haben schlechte 374 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 375 00:26:46,015 --> 00:26:49,071 Schuld." Halte ich für eine Schutzbehauptung. Und dann gibt es 376 00:26:49,071 --> 00:26:53,416 natürlich Inkompetenz. Also so richtig. "Ach, das ging gar nicht anders." - ich habe 377 00:26:53,416 --> 00:26:57,395 neulich so einen Kunden gehabt. Das sieht häufig nicht aus wie Ausreden, 378 00:26:57,395 --> 00:27:01,075 sondern wie Best Practices. Aber ich halte es für Ausreden. Ich habe neulich so einen 379 00:27:01,075 --> 00:27:03,522 Kunden gehabt, die meinen jetzt: "Wir machen jetzt eine Plattform für 380 00:27:03,522 --> 00:27:06,250 Energiehandel", also kritische Infrastruktur, würde man eigentlich sagen. 381 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." 382 00:27:09,796 --> 00:27:13,000 - "Ja, warum denn nicht?" - "Das ist so teuer." 383 00:27:13,897 --> 00:27:17,249 *Publikum lacht* 384 00:27:17,249 --> 00:27:22,275 Verstehe ich nicht. Ich glaube, wir haben da so eine Kaskade aus Ausreden, die vor 385 00:27:22,275 --> 00:27:26,830 uns hergeschoben werden. Der Ansatz, den ich jetzt gehen möchte, ist, dass ich 386 00:27:26,830 --> 00:27:29,650 sage, wir versuchen vielleicht so eine Art Legacy-Faktor zu definieren, den man 387 00:27:29,650 --> 00:27:33,349 an die Software dran schreibt. Und da geht es nicht darum: "Wie schlecht ist die 388 00:27:33,349 --> 00:27:37,155 Software?", sondern "Wie negativ beeinträchtigt wird meine Software, wenn 389 00:27:37,155 --> 00:27:41,157 ich das als Dependency reinnehme?". Also wenn ich jetzt irgendeine Library 390 00:27:41,157 --> 00:27:46,006 reinziehe, wieviel negative Auswirkungen hat das? Das Problem ist aber: Wenn wir 391 00:27:46,006 --> 00:27:49,877 das als Metrik machen und die wird irgendeine Art von Erfolg im Markt haben, 392 00:27:49,877 --> 00:27:53,429 dass die Leute dann natürlich bescheißen werden und werden nach der Metrik 393 00:27:53,429 --> 00:27:56,744 optimieren und nicht nach dem tatsächlichen Ziel der Metrik. Daher ist 394 00:27:56,744 --> 00:28:00,948 das so ein bisschen schwierig, aber es gibt ein Vorbild, was so ein bisschen 395 00:28:00,948 --> 00:28:05,771 funktioniert, nämlich das CVSS - das das Common Vulnerability Scoring System. Das 396 00:28:05,771 --> 00:28:10,095 wird angewendet, um die Problematik von Bugs zu messen. Da haben sich also 397 00:28:10,095 --> 00:28:14,460 Leute zusammengetan und versucht, eine Metrik zu definieren. Und die funktioniert 398 00:28:14,460 --> 00:28:19,729 in der Industrie gut, die wird angenommen. Die Leute lieben das. Das funktioniert 399 00:28:19,729 --> 00:28:24,462 grob so, wie eine historische Risikobewertung. Man guckt halt so, wie 400 00:28:24,462 --> 00:28:28,774 wahrscheinlich ist, dass das passiert, dass das jemand ausnutzt. Da gibt's dann 401 00:28:28,774 --> 00:28:33,027 Kriterien wie: Ist das technisch aufwendig? Kommt man da ran, wenn man 402 00:28:33,027 --> 00:28:38,276 lokal einen Account hat oder auch über Netzwerk? Und was macht man denn kaputt, 403 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 404 00:28:42,951 --> 00:28:46,781 diese Art von Sachen klickt man an, und dann kommt ein Score raus. Das finde ich 405 00:28:46,781 --> 00:28:50,708 eigentlich eine gute Sache. Ich glaube, wir brauchen so ein Risiko-Score - jetzt 406 00:28:50,708 --> 00:28:54,292 nicht für Bugs. Bei Bugs ist es, glaube ich, einfacher zu machen, obwohl es auch 407 00:28:54,292 --> 00:28:58,676 schon viele Detail-Schwierigkeiten hat. Aber eigentlich brauchen wir so eine Art 408 00:28:58,676 --> 00:29:03,695 Risiko-Score, entweder für das Management oder für die Entwickler. Und das sind 409 00:29:03,695 --> 00:29:07,750 getrennte Probleme. Ich glaube, dass es zielführender, sich an die Entwickler zu 410 00:29:07,750 --> 00:29:10,944 halten. Denn ich habe bisher noch fast nie erlebt, dass Management gesagt hat: "Das 411 00:29:10,944 --> 00:29:14,235 muss jetzt besser werden. Und das war nicht nur als PR gemeint." Sondern, aber 412 00:29:14,235 --> 00:29:18,170 Entwickler haben so eine Art Anspruch an ihren Code. Und ich glaube, wenn man denen 413 00:29:18,170 --> 00:29:21,906 hilft zu erkennen, ob sie gerade einen Fehler machen, können wir was stemmen. 414 00:29:21,906 --> 00:29:25,648 Dann habe ich mir gedacht: Welche Dimensionen gibt's denn da? Das ist leider 415 00:29:25,648 --> 00:29:29,813 ein mehrdimensionales Problem. Hier ist eine der Dimensionen, die ich mir überlegt 416 00:29:29,813 --> 00:29:33,962 habe: Sicherheitslöcher. Gut, klar. Wenn der Code Sicherheitslöcher hat, ist das 417 00:29:33,962 --> 00:29:37,258 ein Problem. Aber das ist leider ein offenes Forschungsfeld, wie man die 418 00:29:37,258 --> 00:29:40,789 Sicherheitslöcher finden soll. Und vor allem dafür eine Metrik zu haben. Jetzt 419 00:29:40,789 --> 00:29:44,961 kann man sagen: "Wir haben jetzt 10 Bugs gefunden, also war der Code wahrscheinlich 420 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 421 00:29:49,101 --> 00:29:53,353 dem Code waren. Ist der Rest von dem Code vielleicht super, und das waren 10 422 00:29:53,353 --> 00:29:58,053 Ausrutscher? Das ist leider sehr schwer zu messen. Daher eignet sich das, glaub ich, 423 00:29:58,053 --> 00:30:02,925 nicht als Metrik. In der Industrie gibt es Versuche, mit Code-Smells und statischer 424 00:30:02,925 --> 00:30:07,068 Analyse zu arbeiten. Das ist eine Sache, die im Moment sehr viele Firmen 425 00:30:07,068 --> 00:30:11,207 ausprobieren.Der Erfolg ist bisher eher mäßig. Meine Beobachtung ist, dass man so 426 00:30:11,207 --> 00:30:15,768 ein Tool ausrollt, und der wirft dann zehn Milliarden Warnungen. Und dann schaltet 427 00:30:15,768 --> 00:30:20,235 man so lange die Sensibilität von dem Tool runter, bis die Menge verarbeitbar 428 00:30:20,235 --> 00:30:24,736 ist. Und dann verteilt man das an die Entwickler, und die sagen: "Das sind aber 429 00:30:24,736 --> 00:30:28,717 alles False-Positives", und dann ist das Projekt gescheitert. Dann lässt man das 430 00:30:28,717 --> 00:30:33,343 weiterlaufen, damit es nicht so aussieht, als wäre es gescheitert. Aber dass 431 00:30:33,343 --> 00:30:38,565 tatsächlich was passiert, ist selten. Das ist zwar eine wichtige Dimension, aber ich 432 00:30:38,565 --> 00:30:43,107 glaube, die können wir nicht ordentlich in eine Metrik abbilden. Ich wüsste jedenfalls 433 00:30:43,107 --> 00:30:49,769 nicht, wie. Ich versuche das hier auch an Beispielen zu illustrieren, vielleicht ein 434 00:30:49,769 --> 00:30:55,467 bisschen. Es gibt Extrema: es gibt einmal qmail und sendmail. Das sind eigentlich 435 00:30:55,467 --> 00:30:59,760 ganz gute Illustrationsbeispiele: Das sind beides MTAs, also Programme, die auf einem 436 00:30:59,760 --> 00:31:04,521 Server laufen und Mails weiter verschicken oder annehmen.Und qmail ist gebaut worden 437 00:31:04,521 --> 00:31:08,482 mit dem Ziel, eine sichere Software zu haben, da hat sich jemand erst das Design 438 00:31:08,482 --> 00:31:12,363 überlegt und dann die Software so gebaut. Und sendmail ist erst geschrieben worden, 439 00:31:12,363 --> 00:31:18,015 dann kam jemand und meinte "Ja, vielleicht brauchen wir auch ein Design", und das 440 00:31:18,015 --> 00:31:24,111 sieht man bis heute. qmail ist um 1993 veröffentlicht worden, ging bis Version 441 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 442 00:31:29,850 --> 00:31:36,526 ein, weil es da nie wirklich Probleme gab, das ist sozusagen fertige Software. Das 443 00:31:36,526 --> 00:31:42,156 ist so das eine Ende. Auf der anderen Seite heißt es aber auch, dass neuere 444 00:31:42,156 --> 00:31:46,170 Features einfach nicht drin sind. Es ist immer ein zweischneidiges Schwert. Das ist 445 00:31:46,170 --> 00:31:49,830 das Spektrum, auf dem wir uns bewegen: auf der einen Seite so ein alter Legacy- 446 00:31:49,830 --> 00:31:53,224 Codehaufen, den keiner mehr wirklich verwalten will, außer er wird bezahlt 447 00:31:53,224 --> 00:31:56,585 dafür. Und selbst unter den Leuten, die bezahlt wurden, sind die meisten 448 00:31:56,585 --> 00:32:00,581 weggelaufen, übrigens. Das will einfach niemand haben. Die zweite Dimension, über 449 00:32:00,581 --> 00:32:05,106 die man nachdenken kann, ist: "Gibt es denn noch Wartung dafür?". Das kann man bei 450 00:32:05,106 --> 00:32:08,988 Open-Source-Produkten glücklicherweise ganz gut erkennen. Bei kommerzieller 451 00:32:08,988 --> 00:32:12,573 Software ist das ein bisschen schwieriger, weil da gibts dann vielleicht Patches und 452 00:32:12,573 --> 00:32:16,852 neue Versionen. Aber ob die auch tatsächlich was ändern, ist halt nicht so 453 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 454 00:32:21,549 --> 00:32:24,654 bewerten soll, denn wenn eine Software keine Updates kriegt, muss es ja nicht 455 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 456 00:32:28,779 --> 00:32:34,307 zwar sehr, sehr selten, aber es gibt Beispiele dafür: Zum Beispiel: TeX ist ein 457 00:32:34,307 --> 00:32:39,450 Satzsystem von Donald Knuth. Das hat er geschrieben und ist jetzt fertig. Da gibt 458 00:32:39,450 --> 00:32:44,572 es zwar immer noch Patches, gelegentlich, aber ganz selten. Und die ändern zwei Bits 459 00:32:44,572 --> 00:32:49,299 irgendwo. Das ist im Wesentlichen fertig. Oder libjpeg habe ich hier als Beispiel 460 00:32:49,299 --> 00:32:52,794 genommen, das ist irgendwann geschrieben worden von der Independent JPEG Group um 461 00:32:52,794 --> 00:32:56,071 Tom Lane und das hat eigentlich nie irgendwelche Updates gebraucht. Das war 462 00:32:56,071 --> 00:32:59,467 einfach. Hat auch keine Sicherheitslücken gehabt. Das ist deswegen jetzt nicht 463 00:32:59,467 --> 00:33:03,335 schlecht. Das heißt, dass es nicht so einfach zu sagen: "Es gibt keine Patches 464 00:33:03,335 --> 00:33:08,721 mehr - also ist die Software scheiße." Die Metrik ist also auch sehr schwierig. Wie 465 00:33:08,721 --> 00:33:13,595 machen wir das? Gute Frage. Gut, das hab ich jetzt schon erzählt. Auf der anderen 466 00:33:13,595 --> 00:33:17,871 Seite ist es so: Wenn eine Software sehr häufig geupdatet wird, ist das auch nicht 467 00:33:17,871 --> 00:33:22,411 unbedingt ein gutes Zeichen. Ich habe einen Kunden, der hat eine Software von 468 00:33:22,411 --> 00:33:26,844 einem Drittanbieter, und der releast per GitHub. Und da kommen dann pro Tag fünf 469 00:33:26,844 --> 00:33:31,971 Updates, und da steht aber jedes Mal Release dran. Und gelegentlich brechen die 470 00:33:31,971 --> 00:33:37,346 was, gelegentlich nicht. Da hast du nie irgendeinen Ansatzpunkt, um auch nur zu 471 00:33:37,346 --> 00:33:41,891 beurteilen, ob die Software jetzt gut ist oder nicht. Weil in dem Moment, wo deine 472 00:33:41,891 --> 00:33:47,106 Untersuchung fertig ist, gibts schon wieder 20 neue Versionen. Ja, das ist 473 00:33:47,106 --> 00:33:52,356 eigentlich auch nicht gut. Eine weitere Dimension ist die Dependency-Hölle, die 474 00:33:52,356 --> 00:33:56,950 kennt ja fast jeder, der schon mal Software entwickelt hat. Besonders krass 475 00:33:56,950 --> 00:34:01,703 ausgebildet bei JavaScript, die ein paar Mal sehr öffentlich auf die Fresse 476 00:34:01,703 --> 00:34:05,389 geflogen sind, als zum Beispiel jemand ein Modul zurückgerufen hat, von dem sich dann 477 00:34:05,389 --> 00:34:10,021 herausstellte, dass das irgendwie über transitive Abhängigkeiten in fast allen 478 00:34:10,021 --> 00:34:15,049 Projekten irgendwie drin war. Das müsste man dann transitiv anwenden. Wie gesagt: 479 00:34:15,049 --> 00:34:20,110 Wenn ich eine Software reinlade und die hat 50 andere Dependencies, dann muss ich 480 00:34:20,110 --> 00:34:25,645 die Summe davon nehmen. Die Extrema dabei wären auf der einen Seite so eine Cloud- 481 00:34:25,645 --> 00:34:29,835 Lock-in-Hölle, wo man die Abhängigkeiten gar nicht sieht, sondern man hat halt 482 00:34:29,835 --> 00:34:34,685 irgendwie irgendeine Pipeline, aus der fällt irgendwas raus, und der resolvt am 483 00:34:34,685 --> 00:34:39,107 besten die Abhängigkeiten noch automatisiert während des Bauens und zieht 484 00:34:39,107 --> 00:34:43,660 sich irgendwas aus dem Internet - das ist das eine Extrem. Und das andere Extrem ist 485 00:34:43,660 --> 00:34:48,532 wieder qmail. Der hat halt überhaupt keine Abhängigkeiten, der benutzt die C-Library, 486 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. 487 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. 488 00:34:59,203 --> 00:35:02,580 Aber wie gesagt, es gibt halt mehrere Dimensionen. Wir kommen weiter. Nächste 489 00:35:02,580 --> 00:35:07,256 Dimension ist Codequalität, und das ist so ein bisschen wie Security, aber ich möchte 490 00:35:07,256 --> 00:35:11,814 das verallgemeinern, und zwar unter anderem deswegen, weil es eine relativ 491 00:35:11,814 --> 00:35:16,713 starke Korrelation zwischen vielen Bugs und schlechter Security gibt. Alle 492 00:35:16,713 --> 00:35:21,634 Security-Probleme sind auch ein Bug. Wenn jemand viele normale Bugs hat oder Bugs, 493 00:35:21,634 --> 00:35:25,555 von denen wir nicht wissen oder nicht nachgewiesen haben, dass es ein 494 00:35:25,555 --> 00:35:30,453 Sicherheitsproblem ist, dann ist das im Allgemeinen ein Zeichen dafür, dass da 495 00:35:30,453 --> 00:35:34,457 auch viele Sicherheitslücken drin sein werden. Daher ist es wichtig als 496 00:35:34,457 --> 00:35:39,444 Metrik, selbst wenn es nicht um Sicherheit geht. Wie gesagt, die Trends dazu sind 497 00:35:39,444 --> 00:35:44,786 statische Code-Analyse und Code-Smells. Ich wäre noch dafür hundert Prozent 498 00:35:44,786 --> 00:35:50,341 Coverage beim Unit-Testing zu erwarten. Aber das ist halt auch schwierig, weil da 499 00:35:50,341 --> 00:35:55,009 gibt es verschiedene Messverfahren. Zum Beispiel: Was macht man, wenn mehr als ein 500 00:35:55,009 --> 00:35:59,622 Statement auf einer Zeile steht? Was ist die Granularität des Testens? 501 00:35:59,622 --> 00:36:04,077 Ja, es ist alles nicht so einfach. Aber wir sollten zumindest mal anfangen, 502 00:36:04,077 --> 00:36:07,868 darüber nachzudenken.Und mein Vorschlag wäre, aus den eben erklärten Gründen, dass 503 00:36:07,868 --> 00:36:11,956 wir einfach gucken, welche bekannten Bugs gibt's denn? Wie ist denn so...? Wie viele 504 00:36:11,956 --> 00:36:16,785 Bugs werden bekannt, pro sagen wir mal, Jahr? Und daraus kann man extrapolieren. 505 00:36:16,785 --> 00:36:21,632 Die nächste Näherung wäre, dass man alle Compiler-Warnungen anschaltet, was 506 00:36:21,632 --> 00:36:26,415 erschütternd wenige Software-Hersteller machen in ihren internen Builds. Das ist 507 00:36:26,415 --> 00:36:30,549 wirklich erschreckend.Und was auch viele Leute, die irgendwelche Pipelines in der 508 00:36:30,549 --> 00:36:34,335 Cloud benutzen, gar nicht mitkriegen, wie viele Warnungen da eigentlich rausfliegen. 509 00:36:34,335 --> 00:36:38,224 Das ist eine der wichtigsten Metriken, die ihr als Entwickler habt, und ordentlichen 510 00:36:38,224 --> 00:36:41,825 Code zu produzieren. Also schmeißt Compiler-Warnungen nicht weg, lest sie und 511 00:36:41,825 --> 00:36:46,801 versucht, sie weg zu machen. Und zwar nicht mit einem Pragma. Die nächste 512 00:36:46,801 --> 00:36:53,313 Dimension ist: Welchen Anspruch hat der Typ überhaupt? Das ist mir aufgefallen - 513 00:36:53,313 --> 00:36:58,917 es gab, ich glaube, libexiv2. Das ist so eine Software, um Metadaten in Digital- 514 00:36:58,917 --> 00:37:04,896 Kamera-Bildern zu lesen. Da steht so drin, irgendwie GPS-Koordinaten und was das für 515 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 516 00:37:09,333 --> 00:37:12,456 Standard aussieht. Und es gibt eine OpenSource-Library dafür und da gab's es 517 00:37:12,456 --> 00:37:15,758 einen Haufen Bugs drin und dann hat der Autor von dieser Software irgendwann 518 00:37:15,758 --> 00:37:19,001 einfach geschrieben: "Ja, das dürft ihr halt nicht anwenden auf 519 00:37:19,001 --> 00:37:23,259 unvertrauenswürdige Dateien." Das heißt, der hat nie den Anspruch gehabt, dass 520 00:37:23,259 --> 00:37:26,800 das sicher ist. Aber das stand halt nicht dran, und die Leute haben seine Software 521 00:37:26,800 --> 00:37:30,960 benutzt und angenommen: "Ja, der wird schon darauf geachtet haben." Daher glaube 522 00:37:30,960 --> 00:37:35,492 ich, dass Erste und Beste, was wir machen können, was tatsächlich eine Auswirkung 523 00:37:35,492 --> 00:37:39,209 hat, ist, wenn wir anfangen, an die Software zu schreiben, was eigentlich der 524 00:37:39,209 --> 00:37:42,595 Anspruch war. Also was glauben wir, was wir erreicht haben? Was haben wir 525 00:37:42,595 --> 00:37:47,263 überhaupt versucht. So das ist, glaube ich, wichtig. Eine andere Sache, die es 526 00:37:47,263 --> 00:37:52,198 hier gab, war, dass Leute Features machen, die nach Sicherheit klingen. So, das war 527 00:37:52,198 --> 00:37:55,821 eine Sache, die ich bei Microsoft mal erlebt habe. Da gab es eine Feature namens 528 00:37:55,821 --> 00:37:59,210 "Network Access Protection", und dann bin ich da hingegangen für Thread Modelling 529 00:37:59,210 --> 00:38:02,628 und wollte wissen: "Was sind eure eure Security Guarantees? Was sagt ihr denn 530 00:38:02,628 --> 00:38:06,296 zu?" Und da meinten die so: "Ja, gar nichts. Wir sind kein Security-Feature." 531 00:38:06,296 --> 00:38:10,513 Meinte ich so: "Ja, dann ist der Name vielleicht ein bisschen verwirrend." Aber 532 00:38:10,513 --> 00:38:14,693 sowas passiert halt, weil es einen Disconnect gibt zwischen den Leuten, die 533 00:38:14,693 --> 00:38:20,115 das Projekt machen, und denen, die den Namen wählen und das Marketing machen. Ja, 534 00:38:20,115 --> 00:38:25,190 gut, da gibts auch nochmal Abstufungen. Es gibt halt so explorative Software. 535 00:38:25,190 --> 00:38:28,810 Übrigens, fast alle Open Source Software, die ich so veröffentlicht habe, ist auch 536 00:38:28,810 --> 00:38:32,660 explorativ. Das ist nicht negativ gemeint - im Gegenteil, das ist der beste Weg, wie 537 00:38:32,660 --> 00:38:36,058 man Programmieren lernen kann. Ich habe etwas verstanden, wenn ich es einmal 538 00:38:36,058 --> 00:38:40,541 implementiert habe. Das heißt nicht, dass die Implementation dann gut war. Das 539 00:38:40,541 --> 00:38:45,744 versuche ich natürlich. Aber es ist wichtig, das zu kommunizieren: "Dieser Code 540 00:38:45,744 --> 00:38:50,294 war explorativ." Der ist jetzt vielleicht gut genug abgehangen und hat genug 541 00:38:50,294 --> 00:38:55,405 Real-Life-Tests gemacht und Interoperabilität, dass man ihm trauen kann. Aber der 542 00:38:55,405 --> 00:39:00,857 Anspruch war explorativ. Oder es gibt dieses Szenario: "The guy left." 543 00:39:00,857 --> 00:39:04,590 Das erlebt man gelegentlich bei großen Firmen. "Ja, wir haben hier noch ein Stück 544 00:39:04,590 --> 00:39:07,374 Code, aber wir wissen gar nicht, wer das geschrieben hat." Oder: "Wir wissen schon, 545 00:39:07,374 --> 00:39:11,371 wer das geschrieben hat, aber das war einer der Gründer, und der hat jetzt keine 546 00:39:11,371 --> 00:39:16,050 Zeit mehr für sowas." Oder: "Der Typ, der ist in Ruhestand gegangen", oder 547 00:39:16,050 --> 00:39:20,072 so. Das kommt alles vor. Und das finde ich aber wichtig, dass man das 548 00:39:20,072 --> 00:39:24,693 kommuniziert, weil die Leute, die das benutzen, die wissen, dass halt nicht. 549 00:39:24,693 --> 00:39:29,356 Oder was üblicherweise das beste Szenario ist, vom Anspruch her, ist, dass der Typ, 550 00:39:29,356 --> 00:39:33,258 der das entwickelt, auch der aktuelle Maintainer ist und am Besten versucht, das 551 00:39:33,258 --> 00:39:36,727 kommerziell zu vermarkten, weil der hat dann wirklich ein Interesse daran, dass es 552 00:39:36,727 --> 00:39:40,252 ordentlich wird in den meisten Fällen. Gut, es gibt immer noch mehr Dimensionen, 553 00:39:40,252 --> 00:39:42,612 tut mir leid, dass es so ein komplexes Problem ist. 554 00:39:42,612 --> 00:39:45,735 Es gibt auch das Problem, dass der Typ, 555 00:39:45,735 --> 00:39:51,611 der das umsetzt, die besten Intentionen hatte und die besten Techniken 556 00:39:51,611 --> 00:39:56,651 benutzt, die es gibt, aber dass die Spec, die er umsetzt, scheiße ist. Zum Beispiel 557 00:39:56,651 --> 00:40:00,428 ist XML eine Spec, die richtig scheiße ist. Da stehen Sachen drin, wie, dass man 558 00:40:00,428 --> 00:40:03,856 eine Entity-Expansion machen muss, und damit kann man einen ganz trivial einen 559 00:40:03,856 --> 00:40:07,917 DoS-Angriff machen - auf, im Grunde jeden standardkonformen XML-Parser. Und dann 560 00:40:07,917 --> 00:40:11,881 haben die alle angefangen, irgendwie Konfiguration nachzurüsten, wo man das 561 00:40:11,881 --> 00:40:15,607 ausschalten kann. Aber damit ist man eigentlich nicht mehr standardkonform. 562 00:40:15,607 --> 00:40:19,101 Das kommt häufiger vor, dass Specs schlecht sind. Das ist kein Einzelfall. 563 00:40:19,101 --> 00:40:23,064 Ich will jetzt nicht auf XML zeigen, andere sind auch nicht gut. Oder JSON- 564 00:40:23,064 --> 00:40:27,135 Parser: Da gab es jetzt ein paar Versuche, da sind die Leute einfach herumgegangen 565 00:40:27,135 --> 00:40:31,788 und haben ganz viele Rekursionstiefen aufgemacht und plötzlich platzten die 566 00:40:31,788 --> 00:40:36,450 Parser alle. Oder Window-Messages bei Windows ist ein ganz altes Problem. Das 567 00:40:36,450 --> 00:40:40,591 ist halt erfunden worden, bevor es mehr als einen User gab. Oder so Message-Bus 568 00:40:40,591 --> 00:40:45,691 allgemein, ist so eine Sache, die häufig in so Cloud-Installationen und in großen 569 00:40:45,691 --> 00:40:49,752 Firmen gesehen werden kann. Dass die Leute sagen: "Okay, wenn wir das über die 570 00:40:49,752 --> 00:40:53,954 Datenbank machen, ist es zu langsam. Also bauen wir hier noch ein Message-Bus drum 571 00:40:53,954 --> 00:40:58,110 rum." Und dann kann aber jeder, der Zugriff auf den Message-Bus hat, 572 00:40:58,110 --> 00:41:03,000 auch spoofen oder kann alle anderen Daten sehen. Das ist die Idee schon schlecht 573 00:41:03,000 --> 00:41:06,210 und es ist egal, wie gut ich das umsetze - das wird dadurch nicht 574 00:41:06,210 --> 00:41:11,460 besser. Dann gibt's noch so Lock-In- Probleme. Da weiß ich nicht, ob die hier 575 00:41:11,460 --> 00:41:14,430 wirklich rein gehören, aber ich finde das wichtig genug, dass, wenn wir schon dabei 576 00:41:14,430 --> 00:41:19,740 sind, hier Labels zu vergeben, das auch erwähnen sollten. Zum Beispiel 577 00:41:19,740 --> 00:41:23,460 irgendeine Library, die eigentlich genau das tut, was ich haben will. Aber sie 578 00:41:23,460 --> 00:41:29,310 läuft nur in der Amazon-Cloud. Dann hab ich meine Freiheit, welche Plattform ich 579 00:41:29,310 --> 00:41:32,400 verwende, eingeschränkt, wenn ich diese Library reinziehe. Das ist eigentlich auch 580 00:41:32,400 --> 00:41:40,080 eine Sache, die man vorher kommunizieren müsste - und zwar klar. Oder bei Cryptocode 581 00:41:40,080 --> 00:41:44,070 war lange Zeit ein Problem, dass der assembler-handoptimiert war für die Intel- 582 00:41:44,070 --> 00:41:48,300 Architektur. Aber wenn man dann so Randgruppen-Plattformen wie 583 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 584 00:41:54,660 --> 00:42:01,480 harte Abhängigkeit, aber es schränkt den Benutzer ein. Wenn wir schon 585 00:42:01,480 --> 00:42:04,990 dabei sind, dann können wir auch gleich noch den Ressourcen-Footprint reinziehen. 586 00:42:04,990 --> 00:42:08,170 Es gibt ja häufig so Sachen: "Ja, wir müssen hier sortieren, aber wir rechnen 587 00:42:08,170 --> 00:42:12,070 nur mit zehn Elementen - also machen wir Bubbelsort." Und dann kommt jemand 588 00:42:12,070 --> 00:42:16,060 und tut mehr Elemente rein und plötzlich platzt das. Das ist eigentlich 589 00:42:16,060 --> 00:42:19,240 auch eine Sache, die man kommunizieren sollte: "Mit welchen Größenordnungen gehen 590 00:42:19,240 --> 00:42:25,810 wir hier eigentlich um? Worauf ist das ausgelegt?" Und Achtung! Es geht nicht nur 591 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 592 00:42:29,020 --> 00:42:33,160 eine Library ständig auf der Platte rumschreibt und I/O-Bandbreite frisst oder 593 00:42:33,160 --> 00:42:39,310 versucht, aus dem Netz irgendwas nachzuladen. Also nehmen 594 00:42:39,310 --> 00:42:42,040 wir mal an, das sind die Dimensionen. Es ist ein bisschen 595 00:42:42,040 --> 00:42:44,950 schwierig, da eine Metrik daraus zu bauen, denn eine gute Metrik ist ja immer 596 00:42:44,950 --> 00:42:48,070 zwischen 0 und 1 oder, sagen wir, 0 und 10, das heißt, man hat eine 597 00:42:48,070 --> 00:42:51,880 Vergleichbarkeit. Aber wenn ich sage, wir müssen transitiv die Probleme der 598 00:42:51,880 --> 00:42:55,120 Dependencies mit reinziehen, dann haben wir die Skala nicht, 599 00:42:55,120 --> 00:42:58,420 weil die kann dann beliebig groß werden, wenn ich mehr Dependencies reinziehe. 600 00:42:58,420 --> 00:43:05,530 Daher glaube ich, von diesem Metrik- bzw. Scoreproblem müssen wir weg. Und es gibt 601 00:43:05,530 --> 00:43:08,680 das Problem, wenn ich eine Metrik habe, dass die Leute dann Gaming betreiben, um 602 00:43:08,680 --> 00:43:13,150 die Metrik zu schönen und nicht das Problem zu lösen. Da dachte ich mir: 603 00:43:13,150 --> 00:43:17,980 "Nennen wir es mal Legacy-Score... aber Score geht eigentlich nicht... hmm... 604 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 605 00:43:23,380 --> 00:43:26,740 eigentlich auch verschiedene Ansätze, was man sagen kann..." Man könnte sagen für die 606 00:43:26,740 --> 00:43:31,570 gesamte Software, dass sich so eine Art Score ausrechne. Und das ist wie, sag ich 607 00:43:31,570 --> 00:43:35,260 mal, bei einer Versicherung, dass sie halt guckt, wie viel, wie wahrscheinlich ist 608 00:43:35,260 --> 00:43:39,820 es, dass ich hier zahlen muss? So in der Richtung Risikobewertung. Oder ich kann 609 00:43:39,820 --> 00:43:43,420 das für ein Modul machen. Oder für Manager, dass der Manager sagt: 610 00:43:43,420 --> 00:43:47,980 "Das Modul ziehen wir nicht rein, das ist zu riskant." Oder für Entwickler. Oder 611 00:43:47,980 --> 00:43:52,210 vielleicht sogar pro Funktion? Und da hab ich mir gedacht: "Okay, gucken wir doch 612 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 613 00:43:55,090 --> 00:43:58,570 ich habe einen schönen Standard gefunden von 1993: Kompakte Darstellung 614 00:43:58,570 --> 00:44:01,930 mehrdimensioneller Daten, nämlich, den Geek Code. Wer hier kennt den Geek Code? 615 00:44:01,930 --> 00:44:08,480 Das jetzt für die älteren unter euch. Das sah so aus: die Formatierung 616 00:44:08,480 --> 00:44:13,310 war so ein bisschen als als Scherz auf PGP. Die Idee war, dass man sich selbst 617 00:44:13,310 --> 00:44:17,990 beschreibt. Also GED heißt zum Beispiel Geek Education Sector. Und danach? Das 618 00:44:17,990 --> 00:44:22,460 sind alles irgendwelche Dimensionen. Und dann eine Bewertung. Zum Beispiel: s heißt: 619 00:44:22,460 --> 00:44:28,370 "Wie groß bin ich?" Und das haben die Leute in ihre Signature getan und im Usenet 620 00:44:28,370 --> 00:44:31,370 verbreitet. Und dann konnte man so grob sich eine Vorstellung machen, was der 621 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 622 00:44:34,700 --> 00:44:38,870 sozusagen der Vorgänger von Facebook könnte man aus heutiger Sicht sagen. Die 623 00:44:38,870 --> 00:44:42,320 Leute haben freiwillig alles Mögliche über sich verraten. Aber die Idee ist ja 624 00:44:42,320 --> 00:44:44,480 vielleicht nicht schlecht und habe ich mir gedacht: "Jetzt versuchen wir 625 00:44:44,480 --> 00:44:48,500 doch mal, die Dimensionen, die ich hier formuliert habe, auf so eine Art Score 626 00:44:48,500 --> 00:44:53,810 abzubilden." Und das ist gar nicht so einfach, deswegen habe ich auch den 627 00:44:53,810 --> 00:44:56,360 Vortrag hier erst einmal auf deutsch gemacht, bevor ich das international 628 00:44:56,360 --> 00:44:59,630 vortrage, weil ich glaube, da muss noch gefeilt werden. Ich würde mich über euer 629 00:44:59,630 --> 00:45:03,440 Feedback da auch wirklich freuen, wenn ihr noch Vorschläge habt. Ich zeig jetzt mal 630 00:45:03,440 --> 00:45:07,940 den Entwurf, den ich gemacht habe bisher. Die Idee wäre, dass man es als Autor 631 00:45:07,940 --> 00:45:11,570 von einer Library in einen Kommentar reinschreibt, oben. Und dann hat man so 632 00:45:11,570 --> 00:45:15,770 eine Art, ich sage mal, Hundepfeife. Der andere Entwickler kann es lesen und 633 00:45:15,770 --> 00:45:21,800 versteht, was gemeint ist. Das hier ist jetzt noch relativ klar: "Wer besitzt 634 00:45:21,800 --> 00:45:26,690 eigentlich den Code?" Und da ist der schlimmste Fall natürlich: man sieht 635 00:45:26,690 --> 00:45:29,960 den gar nicht. Man hat nicht mal eine Kopie davon, sondern das läuft irgendwo in 636 00:45:29,960 --> 00:45:33,770 der Cloud. Das wäre hier klar die Dimension. Dann... das ist so ein bisschen 637 00:45:33,770 --> 00:45:37,070 verwandt, aber nicht genau dasselbe: "Ich habe den Code, und ich kann ihn 638 00:45:37,070 --> 00:45:41,210 ändern." Oder: "Ich kann ihn nur lesen", sowas. Oder: "Der ist verloren gegangen." Oder 639 00:45:41,210 --> 00:45:51,530 so das Huawei Modell: "Wir lassen die Regierung reingucken." Ja, das ist jetzt so 640 00:45:51,530 --> 00:45:54,320 ein bisschen mit dem scherzenden Auge natürlich, aber ich finde die Idee 641 00:45:54,320 --> 00:45:59,720 eigentlich, muss ich sagen, ganz attraktiv. Ich werde das bei meinem 642 00:45:59,720 --> 00:46:05,150 eigenen Code mal einbauen. Das Problem bei sowas ist natürlich, dass man 643 00:46:05,150 --> 00:46:08,750 gucken muss, dass das obere Ende auch tatsächlich das obere Ende ist und nur von 644 00:46:08,750 --> 00:46:13,080 wenigen erreicht werden wird. Dass jemand tatsächlich Sicherheitszusagen macht, ist 645 00:46:13,080 --> 00:46:19,020 sehr selten. Eigentlich fast nie. Dann gibt es so Leute, die machen seit 20 646 00:46:19,020 --> 00:46:22,200 Jahren immer nur dasselbe. Zum Beispiel der Typ, der Zstandard macht, das so eine 647 00:46:22,200 --> 00:46:26,130 Kompressions-Library, die jetzt über Facebook released wurde, der hat vorher 648 00:46:26,130 --> 00:46:30,780 LZ4 gemacht und macht seit Ewigkeiten Kompressosions-Algorithmen. Da kann man 649 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 650 00:46:35,250 --> 00:46:38,490 der Typ, der das geschrieben hat, sondern ich muss es hier nur verwalten. Ich hab 651 00:46:38,490 --> 00:46:42,990 das geerbt, ich bin hier der Azubi." Das müsste eigentlich dran stehen, finde ich. 652 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 653 00:46:48,390 --> 00:46:51,420 halt von: "Ich habe einen Beweis, und den kannst du nachvollziehen." Bis über: "Ich 654 00:46:51,420 --> 00:46:56,460 habe einen Beweis, und den kannst du nicht nachvollziehen." Oder: "Naja, wir versuchen 655 00:46:56,460 --> 00:47:00,480 immer, alle Bugs zu schließen", wobei schließen und fixen ein Unterschied ist. 656 00:47:00,480 --> 00:47:05,850 Also aufgepasst! Immer schön in den Bugtracker gucken. Und dann gibt's halt die 657 00:47:05,850 --> 00:47:09,000 Leute, die argumentieren: "Ja, das ist doch gar kein Security Problem, der crasht 658 00:47:09,000 --> 00:47:14,670 doch bloß." Also Leute, die entweder keine Ahnung haben oder böswillig sind. Und das 659 00:47:14,670 --> 00:47:18,810 finde ich wichtig, das zu kommunizieren. Die meisten Leute sind hier bei Stand C-, 660 00:47:18,810 --> 00:47:24,090 da draußen, oder sie haben überhaupt keinen Bugtracker. Das gibt's auch noch 661 00:47:24,090 --> 00:47:28,920 vereinzelt. Dann hab ich mir gedacht: "Vielleicht müssen wir noch sagen: 662 00:47:28,920 --> 00:47:33,540 'Welche Art von Design ist denn in die Entwicklung eingeflossen?'" Das geht halt 663 00:47:33,540 --> 00:47:37,470 los mit: "Ja, alle Buzzwords angeklickt. Wir haben hier Least Privilege usw." 664 00:47:37,470 --> 00:47:42,540 Dann gibt es einen relativ großen Sprung zu: "Naja, wir validieren unsere 665 00:47:42,540 --> 00:47:48,070 Inputs." Das ist schon mal gut, aber es geht halt bis runter zu so 666 00:47:48,070 --> 00:47:51,232 Bullshit-Blabla, von wegen: "Ja, wir haben doch einen Anti-Virus." 667 00:47:51,232 --> 00:47:53,575 *Publikum lacht* 668 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 669 00:47:59,176 --> 00:48:06,097 Art Label. Die Idee kam mir eigentlich, als ich mal in Amerika so eine 670 00:48:06,097 --> 00:48:10,152 Multi-Vitamin-Tabletten-Packung gekauft habe, denn da ist hinten so eine riesige 671 00:48:10,152 --> 00:48:14,255 Tabelle drauf, mit den Supplement Facts und da steht drauf: "Dieses Vitamin, so 672 00:48:14,255 --> 00:48:18,012 und so viel Prozent der Recommended Daily Allowance." Und da kann man dann sehen: 673 00:48:18,012 --> 00:48:22,567 "Okay, die wollen mich verarschen." Weil da steht dann sowas wie: "Vitamin C: 5000%" 674 00:48:22,567 --> 00:48:27,432 So: "Viel hilft viel." Also ich meine, da muss man natürlich trotzdem, als 675 00:48:27,432 --> 00:48:31,606 der, der dieses Label liest, ein grobes Verständnis haben, was das bedeutet. Aber 676 00:48:31,606 --> 00:48:36,538 immerhin. Ich glaube, das ist ein Weg, den wir mal ausprobieren können. Übrigens das 677 00:48:36,538 --> 00:48:42,133 hier unten: "The author left" und "project abandoned" ist häufiger, als man glaubt. 678 00:48:42,133 --> 00:48:46,668 Volatility: das versucht, so ein bisschen dieses Agilitätsproblem 679 00:48:46,668 --> 00:48:51,040 anzugehen. Dass Leute einfach häufiger releasen, als man prüfen kann, ob das 680 00:48:51,040 --> 00:48:55,159 jetzt ordentlich ist oder nicht. Aber so richtig eine gute Lösung gibt es 681 00:48:55,159 --> 00:48:59,743 eigentlich nicht. Was ich so persönlich als am entspanntesten empfinde, ist Vim. 682 00:48:59,743 --> 00:49:04,345 Vim bringt im Grunde täglich Updates raus, aber man merkt nie, dass sich irgendwas 683 00:49:04,345 --> 00:49:08,893 verändert hat. Weil die Software compiled vorher und nachher, alle Sachen, die ich 684 00:49:08,893 --> 00:49:13,706 benutzt habe, gehen noch. Das ist, glaube ich, das Optimalziel, was man da erreichen 685 00:49:13,706 --> 00:49:17,203 kann bei Software, dass der Kunde gar nicht merkt, ob gepatcht wurde oder nicht, 686 00:49:17,203 --> 00:49:20,885 weil das einfach alles weiter funktioniert. Die Spec hatte ich ja schon 687 00:49:20,885 --> 00:49:26,271 erwähnt. Die müssen wir auch irgendwie abbilden, ob die Spec was taugt. Und da 688 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 689 00:49:31,933 --> 00:49:36,007 leider auch selten. Häufig kommt es vor, dass die Spec hinter einer Paywall ist, 690 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- 691 00:49:39,835 --> 00:49:44,031 Typ werde jetzt nicht zur ISO laufen und mir für ein paar tausend Euro irgendwie 692 00:49:44,031 --> 00:49:49,421 die MPEG-Spec runterladen um zu gucken, ob der MPEG-Player ordentlich ist, den ich da 693 00:49:49,421 --> 00:49:54,225 gerade runtergeladen hab. Dann haben wir noch Dependecies. Das müsste man 694 00:49:54,225 --> 00:49:57,723 eigentlich transitiv machen, da ist mir jetzt auch nicht klar, wie man das auf den 695 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. 696 00:50:01,824 --> 00:50:06,636 Also wie sieht das in der Praxis aus? Ich habe hier mal versucht, ein paar 697 00:50:06,636 --> 00:50:10,657 Beispiele zu machen - ungefähr so. Das Problem ist halt, dass die Dimensionen 698 00:50:10,657 --> 00:50:15,330 jeweils auf beiden Seiten subjektiv sind. Das heißt, für den einen oder anderen ist 699 00:50:15,330 --> 00:50:20,768 es vielleicht okay, wenn er den Quellcode nicht hat, solange es noch Wartungen gibt. 700 00:50:20,768 --> 00:50:25,259 Also Leute, die Windows einsetzen, zum Beispiel. Für die ist es okay, 701 00:50:25,259 --> 00:50:29,070 wenn es den Quellcode nicht gibt. Aber das heißt eben, dass der 702 00:50:29,070 --> 00:50:33,399 Score auch nicht einfach eine Zahl sein kann, sondern er muss pro Dimensionen 703 00:50:33,399 --> 00:50:38,295 einen Wert haben. Das sieht jetzt irgendwie schwer zu lesen aus - und ist es auch. 704 00:50:38,295 --> 00:50:43,166 Aber bei dem Geek Code hat sich herausgestellt: wenn man so ein paar Tage 705 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 706 00:50:47,637 --> 00:50:51,557 hab mir dann noch überlegt: "Eigentlich brauchst du jetzt noch eine schöne Domain." 707 00:50:51,557 --> 00:50:56,079 Habe mir überlegt: "legacyco.de wäre super!", aber die hat schon Xing gekauft. 708 00:50:56,079 --> 00:50:59,108 *Publikum lacht* 709 00:51:00,042 --> 00:51:05,852 Ja gut, das war so mein Vorschlag. Ich hoffe, ich kriege jetzt eine Menge gute Ideen, 710 00:51:05,852 --> 00:51:09,893 was man da noch verbessern kann oder vielleicht auch andere Vorschläge, die 711 00:51:09,893 --> 00:51:14,282 keinen Score beinhalten. Vielleicht ist ja auch der ganze Ansatz schon falsch. Aber 712 00:51:14,282 --> 00:51:18,240 ich bin mir sicher, dass wir als Industrie jetzt mal loslegen müssen. Ich glaube, 713 00:51:18,240 --> 00:51:22,553 reaktiv funktioniert das nicht, sondern wir müssen gucken, wie wir im 714 00:51:22,553 --> 00:51:26,820 Entwicklungsprozess erstens dafür sorgen, dass die Leute die Entscheidungen, welche 715 00:51:26,820 --> 00:51:30,654 Produkte sie reinziehen, welche Dependencies sie reinziehen, auf 716 00:51:30,654 --> 00:51:36,671 informierter Grundlage treffen können. Ich hätte gern, dass es so einen Score gibt, 717 00:51:36,671 --> 00:51:41,510 wo man dann auch als Entwickler einen Anreiz hat, das besser werden zu lassen, 718 00:51:41,510 --> 00:51:46,426 weil man sehen kann: "An der Stelle bin ich noch nicht der Standard, 719 00:51:46,426 --> 00:51:49,610 der ich sein möchte." Ansonsten, wir haben jetzt die 720 00:51:49,610 --> 00:51:53,647 Saal-Mikrofone. Ich hoffe, die Signal- Engel sind schon so weit. Ansonsten, Fragen 721 00:51:53,647 --> 00:51:58,069 nehme ich auch gern per Mail entgegen. Vielen Dank für die Aufmerksamkeit. 722 00:51:58,069 --> 00:52:09,897 *Applaus* 723 00:52:10,565 --> 00:52:13,514 Herold: Dann können jetzt alle an die Mikrofone gehen, die noch Fragen haben. 724 00:52:13,514 --> 00:52:16,685 Wir haben direkt eine Frage aus dem Internet. Bitte! 725 00:52:16,685 --> 00:52:20,779 Anonym: Gibt es Projekte im echten Leben, wo das Problem mit der Komplexität deiner 726 00:52:20,779 --> 00:52:24,503 Meinung nach richtig gemacht wurde? Und wenn ja, wo findet man die? 727 00:52:24,503 --> 00:52:30,910 Fefe: Sehr selten. Es gab einmal vor ein paar Jahren gab es so einen Push, 728 00:52:30,910 --> 00:52:34,660 wo viele Leute angefangen haben, Software zu veröffentlichen und damit zu bewerben, 729 00:52:34,660 --> 00:52:40,990 dass sie besonders klein oder minimal sein soll. Da bin ich auch einer von. Aber es 730 00:52:40,990 --> 00:52:44,440 stellt sich halt raus, dass es auch andere Projekte gibt, die halt minimal dran 731 00:52:44,440 --> 00:52:47,110 schreiben, weil sie finden, es sei minimal, und das ist dann aber nicht 732 00:52:47,110 --> 00:52:52,030 minimal. Zum Beispiel gab es neulich ein Announcement von einem Systemd-Clone in 733 00:52:52,030 --> 00:52:56,830 Rust, und ich bin eigentlich ein Fan von Rust und kein Fan von Systemd. Deswegen 734 00:52:56,830 --> 00:53:01,990 fände ich da ein Ersatz schon gut. Aber Rust erzeugt keine kleinen 735 00:53:01,990 --> 00:53:06,370 Binaries, sondern da fallen so große Monster raus. Das heißt, das ist dann zwar 736 00:53:06,370 --> 00:53:11,620 minimal im Sinne von, wie viel Features es implementiert, aber das Endprodukt ist 737 00:53:11,620 --> 00:53:15,280 halt riesig groß. Da kann jetzt der Typ nichts für, der das geschrieben hat. Das 738 00:53:15,280 --> 00:53:19,182 ist im Moment noch ein Rust-Problem, und da arbeiten die auch dran. 739 00:53:19,182 --> 00:53:24,310 Aber "minmal", "Komplexität", "gering", ist eine subjektive Sache. Ich 740 00:53:24,310 --> 00:53:28,360 persönlich habe immer die Software von Dan[iel] Bernstein sehr gut gefunden, also 741 00:53:28,360 --> 00:53:32,980 qmail und djbdns sind gute Beispiele dafür, wie ein Code aussieht, der 742 00:53:32,980 --> 00:53:38,800 Komplexität gut managed und klein hält. Aber es ist ein kleines Feld. Man findet 743 00:53:38,800 --> 00:53:44,970 da nicht so viele Beispiele von Software, die gut gemacht und unterkomplex ist. 744 00:53:46,505 --> 00:53:52,170 Herold: Dann, am Mikrofon 10 hatte ich gesehen. Kann das sein? Ich habe gerade 745 00:53:52,170 --> 00:53:56,280 ein Signal bekommen... Nein? Alles klar. Da machen wir weiter mit Mikrofon zwei. 746 00:53:56,280 --> 00:53:59,574 Bitte! Anonym: Vielen Dank für die spannenden 747 00:53:59,574 --> 00:54:04,830 Ideen! Meine Frage geht so ein bisschen auf: Ist das nicht zu freiwillig und zu 748 00:54:04,830 --> 00:54:08,150 selbst auferlegt? Ist das nicht zu CDU- mäßig als Lösung? 749 00:54:08,150 --> 00:54:11,454 *Fefe lacht* Was hält nicht davon ab, einfach zu sagen 750 00:54:11,454 --> 00:54:15,160 Ich bin M+++, obwohl ich das vielleicht gar nicht bin? 751 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 752 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 753 00:54:24,602 --> 00:54:29,619 losgeht, dass es dann auch ein Druck gibt aus der Community, der die Leute davon 754 00:54:29,619 --> 00:54:34,831 abhält zu lügen. Also meine Erfahrung mit Entwicklern ist, dass die meisten Leute 755 00:54:34,831 --> 00:54:38,848 eigentlich gute Menschen sind. Die möchten keinen Scheiß machen, niemand 756 00:54:38,848 --> 00:54:43,162 möchte lügen. Das heißt, wenn du denen eine Gelegenheit gibst darzustellen, dass 757 00:54:43,162 --> 00:54:46,937 das noch nicht fertig ist, dann werden sie das auch tun, im Allgemeinen. Außer du 758 00:54:46,937 --> 00:54:50,271 hast jemanden, der es wirklich nicht beurteilen kann. Das Risiko kriegst du mit 759 00:54:50,271 --> 00:54:54,463 dem Label nicht weg. Aber ich glaube, es ist schon mal ein guter Schritt, wenn wir 760 00:54:54,463 --> 00:54:58,681 den den Entwicklern, die gerade dabei sind, sich eine Dependancy ins Projekt zu 761 00:54:58,681 --> 00:55:02,985 ziehen, irgendwas in die Hand geben, woran sie erkennen können: "Ist das denn jetzt 762 00:55:02,985 --> 00:55:07,257 ernst gemeint, oder war das hier nur so ein Spielprojekt?" Und ich glaube, das ist 763 00:55:07,257 --> 00:55:10,891 ein guter Anfang. Aber ich weiß es natürlich auch nicht. Müssen wir 764 00:55:10,891 --> 00:55:17,549 ausrollen, müssen wir gucken. Herold: Dann am Mikrofon 6, war zuerst. 765 00:55:17,549 --> 00:55:24,453 Anonym: Das geht vielleicht auch jetzt in dieselbe Richtung wie der Fragende vor 766 00:55:24,453 --> 00:55:31,290 mir. Vielleicht. Könnte man wie so eine Art Rechtsprechungs-Instanz installieren? 767 00:55:31,290 --> 00:55:37,701 Ich meine, kein Entwickler-Team aus Indien wird das als Malus akzeptieren, wenn da 768 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 769 00:55:43,140 --> 00:55:46,838 sinnvolle Idee? Wie könnte man das umsetzen? 770 00:55:47,361 --> 00:55:51,361 Fefe: Also es ging jetzt nicht um Indien, das hätte auch Massachusetts sein können, 771 00:55:51,361 --> 00:55:54,725 sondern es geht darum, dass das Team halt nicht der ist, der das geschrieben hat, 772 00:55:54,725 --> 00:55:58,953 sondern irgendjemand hat es jetzt halt am Bein, weil wir brauchten einen Maintainer. 773 00:55:58,953 --> 00:56:04,293 Das ist immer ein Problem. Und natürlich wird es auch irgendwie Betrüger geben. 774 00:56:04,293 --> 00:56:09,630 Aber ich hoffe, dass man die dann erkennt, weil die halt in allen Feldern das Beste 775 00:56:09,630 --> 00:56:13,611 jeweils anklicken. Aber ich weiß es halt auch nicht, das muss man ausprobieren. 776 00:56:13,611 --> 00:56:17,483 Also meine Erfahrung ist, dass an anderer Stelle Communities schon helfen, den 777 00:56:17,483 --> 00:56:21,814 Standard hochzuziehen, wenn man zumindest einfach mal anfängt und sagt: "Das 778 00:56:21,814 --> 00:56:26,136 hier ist wichtig, da müssen wir drüber reden." Und das ist, glaube ich, ein 779 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 780 00:56:31,395 --> 00:56:35,428 das?", und supervolatil ist nicht der höchste Score, dass man vielleicht 781 00:56:35,428 --> 00:56:39,722 irgendwie auf die Art auch Ideen transportiert kriegt? Dass man sagt: 782 00:56:39,722 --> 00:56:44,161 "Vielleicht musst du nochmal drüber nachdenken, wie du dein Projekt aufziehst." 783 00:56:45,811 --> 00:56:50,310 Herold: Dann bitte am Mikrofon 1. Anonym: Ich hab grad drüber 784 00:56:50,310 --> 00:56:54,073 nachgedacht, ob das nicht so etwas ähnliches ist, wozu die 785 00:56:54,073 --> 00:56:57,720 Lebensmittelindustrie so ein bisschen genötigt werden musste: Alle Inhaltsstoffe 786 00:56:57,720 --> 00:57:02,270 reinzuschreiben, Allergene reinzuschreiben und so. Und deshalb die Frage: Sollten wir 787 00:57:02,270 --> 00:57:06,510 nicht möglichst bald als Follow-Up entwickeln, so eine Art Software Code- 788 00:57:06,510 --> 00:57:10,085 Ampel einzuführen. Und dann rot, gelb und grün daraus zu machen. 789 00:57:10,085 --> 00:57:12,822 *Lacht* Fefe: Ja, genau. Das war ja eigentlich die 790 00:57:12,822 --> 00:57:16,161 Idee. Aber ich glaube, du kannst es nicht runterbrechen auf einen Score, weil 791 00:57:16,161 --> 00:57:19,253 einige Teile davon subjektiv sind. Das ist ja bei Lebensmitteln eher nicht so, 792 00:57:19,253 --> 00:57:22,932 sondern da vertraust du der Behörde. Die Behörde sagt irgendwie so und so viel 793 00:57:22,932 --> 00:57:26,620 Quecksilber ist Maximum. Und wenn mehr, ist es nicht gut. Da fängst du nicht 794 00:57:26,620 --> 00:57:30,078 an zu verhandeln. Aber wenn jetzt die Software kommt und sagt: "Wir ziehen 795 00:57:30,078 --> 00:57:33,922 hier noch ein MySQL rein", und du weißt es nicht besser, dann sagst du halt: 796 00:57:33,922 --> 00:57:38,379 "Okay". Das ist eine Sache, die muss man auch dem Endbenutzer überlassen. Weil du 797 00:57:38,379 --> 00:57:43,382 willst ja auch nicht, zum Beispiel, OCaml benachteiligen, weil 798 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 799 00:57:46,965 --> 00:57:51,137 keinen Score für?" Das ist halt nicht C. Ist es jetzt besser oder nicht? Das 800 00:57:51,137 --> 00:57:55,221 muss ja offen genug bleiben. Deswegen glaube ich auch nicht an Schiedsgerichte 801 00:57:55,221 --> 00:57:58,887 und irgendwie Organisationen, die Labels vergeben. Das ist doch nie gut 802 00:57:58,887 --> 00:58:02,851 ausgegangen, in meiner Erfahrung. Ich glaube, das muss aus der Community kommen, 803 00:58:02,851 --> 00:58:06,423 und das muss so laufen, dass man das Gefühl hat, ich tue jetzt hier etwas 804 00:58:06,423 --> 00:58:09,748 Besseres, und ich kann den Erfolg sehen, weil mein Score jetzt hier besser wird. 805 00:58:09,748 --> 00:58:12,763 Ich kann jetzt hier ++ schreiben. Ist jetzt die Hoffnung. Ich weiß auch nicht, 806 00:58:12,763 --> 00:58:17,678 ob es geht. Herold: Dann bitte nochmal Mikrofon 2. 807 00:58:17,678 --> 00:58:22,130 Anonym: Mir hat eine Dimension gefehlt, die ein bisschen in Wartungen passt, aber 808 00:58:22,130 --> 00:58:26,171 nicht perfekt. Wir sind ja hier ein Raum voller Leute, die Sachen selbst in die Hand 809 00:58:26,171 --> 00:58:29,487 nehmen. Wie leicht ist es denn mitzumachen? Wie leicht ist es Bugs selbst 810 00:58:29,487 --> 00:58:33,347 im Upstream zu fixen? Muss man erstmal einen Vertrag unterschreiben, wo man alle Rechte 811 00:58:33,347 --> 00:58:37,136 abtritt, oder? Das ist, glaube ich, auch noch eine wichtige Dimension. 812 00:58:37,136 --> 00:58:41,254 Fefe: Das stimmt. Ich habe das versucht abzubilden, über den: "Ich hab den Code 813 00:58:41,254 --> 00:58:45,464 und darf ihn ändern." Aber das Problem ist, dass das derjenige, der das Projekt 814 00:58:45,464 --> 00:58:49,020 verwaltet, üblicherweise nicht gut beurteilen kann, sondern der wird immer 815 00:58:49,020 --> 00:58:53,007 sagen: "Ja, ist alles total offen hier". Das geht, glaube ich, nicht über so einen 816 00:58:53,007 --> 00:58:55,981 Score. Aber man kann es natürlich versuchen. 817 00:58:57,221 --> 00:59:01,799 Herold: Dann bitte Mikrofon 8. Anonym: Ist fehlendes IPv6 für dich ein 818 00:59:01,799 --> 00:59:04,998 Bug oder ein nicht implementiertes Feature? 819 00:59:04,998 --> 00:59:10,336 Fefe: Das ist eine der subjektiven Fragen. Für mich persönlich ist es ein Fehler, 820 00:59:10,336 --> 00:59:13,820 wenn kein IPv6 drin ist. Aber es gibt genug Firmen da draußen, die sagen: "Das 821 00:59:13,820 --> 00:59:17,272 haben wir eh nicht." Anonym: Danke. 822 00:59:17,272 --> 00:59:21,804 Herold: Dann bitte Mikrofon 7. Anonym: Die Intention, dass die Community 823 00:59:21,804 --> 00:59:26,937 das schon richten wird. Du hattest CVSS als relativ positives Beispiel 824 00:59:26,937 --> 00:59:31,625 dargestellt. Vor fünf Jahren war Heartbleed in OpenSSL, das hat einen CVSS- 825 00:59:31,625 --> 00:59:36,515 Bug von 5,0 gehabt, und Bruce Schneier kommentierte: "Auf einer Skala von 1 bis 10 826 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, 827 00:59:42,040 --> 00:59:48,444 und ich finde es gut, dass du aufgezeigt hast, wie komplex das ist, denn wir haben 828 00:59:48,444 --> 00:59:54,311 halt keinen Standard. Was bedeutet denn zum Beispiel eben "minimal"? Oder wenn eine 829 00:59:54,311 --> 00:59:59,230 Zwei-Faktor-Authentifizierungs-Umgehung ein Sicherheitsbug ist, ist dann jede 830 00:59:59,230 --> 01:00:01,970 Anwendung mit einer Ein-Faktor- Authentifizierung automatisch ein 831 01:00:01,970 --> 01:00:05,158 Sicherheitsbug? Fefe: Ja, du hast völlig recht, das sind 832 01:00:05,158 --> 01:00:10,747 offene Forschungsfragen, wie man das lösen soll. Ich habe da auch keine 833 01:00:10,747 --> 01:00:15,679 guten Antworten. Die die Heartbleed Sache hätte man vielleicht klären können, indem 834 01:00:15,679 --> 01:00:19,085 man sagt: "Welche Zusagen machen wir denn?" Wenn die Zusagen gebrochen sind, 835 01:00:19,085 --> 01:00:22,790 dann ist automatisch Totalschaden. Aber wir haben halt häufig - ich habe das ja auf 836 01:00:22,790 --> 01:00:25,730 einer Folie gehabt - Projekte, die klingen so, als wenn sie ein 837 01:00:25,730 --> 01:00:29,390 Security Feature implementieren. Und wenn du sie dann fragst, welche Zusagen sie 838 01:00:29,390 --> 01:00:33,530 machen, kommt dann halt: "Ja ne, gar keine. Wer mich einsetzt, ist selber 839 01:00:33,530 --> 01:00:37,310 schuld." Und da müssen irgendwie von wegkommen. Ich glaube, das geht nur, wenn 840 01:00:37,310 --> 01:00:41,630 man bei den Leuten so ein bisschen das Empfinden schärft dafür, dass sie gerade 841 01:00:41,630 --> 01:00:45,650 die Legacy von morgen schreiben. Die Leute tun immer so, als wenn Legacy vom Himmel 842 01:00:45,650 --> 01:00:49,430 fällt. Das haben wir geerbt. Ne, du schreibst gerade halt nicht von heute die 843 01:00:49,430 --> 01:00:54,380 Legacy, sondern die von morgen. Herold: Dann gab es noch eine Frage aus 844 01:00:54,380 --> 01:00:57,560 dem Internet, bitte! Anonym: Ja, bei deinem Bewertungsschema: 845 01:00:57,560 --> 01:01:02,150 Wie soll das bei Projekten funktionieren, bei denen es gar keinen Owner mehr gibt, 846 01:01:02,150 --> 01:01:08,030 der das dranschreiben könnte? Fefe: Naja, irgendwann, wenn sich das gut 847 01:01:08,030 --> 01:01:11,210 genug durchsetzt, ist die Abwesenheit eines Labels an sich schon ein schlechtes 848 01:01:11,210 --> 01:01:16,280 Zeichen. Aber das wird natürlich ewig dauern, bis wir so weit sind. Also ist nur 849 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 850 01:01:20,000 --> 01:01:24,080 klebt, kann man vielleicht irgendwie eine Community-Entscheidung auf GitHub machen. 851 01:01:24,080 --> 01:01:27,472 Eine Verurteilung durch den Mob? *Lachen* 852 01:01:28,688 --> 01:01:33,530 Herold: Dann bitte am Mikrofon 4. Anonym: Das sind jetzt doch relativ grobe 853 01:01:33,530 --> 01:01:36,380 Kategorien. Und gerade bei Enterprise Software als Entwickler wirst du es jetzt 854 01:01:36,380 --> 01:01:39,530 schwer schaffen, irgendwie bei "Lizenz" eine Kategorie hochzukommen. Ist denn deine 855 01:01:39,530 --> 01:01:42,800 Hoffnung, dass tatsächlich Entwickler dazu angeregt werden, existierende Software zu 856 01:01:42,800 --> 01:01:45,988 verbessern oder mehr in die Richtung, wenn ich jetzt eine neue Software mach, dass 857 01:01:45,988 --> 01:01:48,830 ich mir mal Gedanken mach: "Was will ich überhaupt erreichen und was für Garantien 858 01:01:48,830 --> 01:01:52,070 gebe ich?" Fefe: Das richtet sich vor allem an 859 01:01:52,070 --> 01:01:57,260 Hobbyisten im Moment, weil im Enterprise Umfeld sind die sind die Einschränkungen 860 01:01:57,260 --> 01:02:01,220 der Umgebung andere. Da wirst du halt bezahlt von der Firma. Und der Typ, der 861 01:02:01,220 --> 01:02:05,180 dich bezahlt, entscheidet, wofür du deine Zeit ausgibt. Und da hast du gar nicht die 862 01:02:05,180 --> 01:02:08,030 Option, jetzt rumzulaufen und den alten Code besser zu machen, weil es einen 863 01:02:08,030 --> 01:02:11,960 riesigen Backlog an Sachen gibt, die du noch machen musst. Besonders so in Agile 864 01:02:11,960 --> 01:02:17,270 Umfeldern wird ja sozusagen jede freie Minute noch rausoptimiert. Und da stellt 865 01:02:17,270 --> 01:02:20,240 sich die Frage gar nicht, ob ich jetzt rumlaufe und alten Code besser mache. 866 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 867 01:02:23,270 --> 01:02:27,500 nicht viel Hoffnung gehabt. Aber Open Source hat gewaltigen Einfluss ausgeübt 868 01:02:27,500 --> 01:02:32,760 auf Enterprise Umgebung. Das merkt man vielleicht aus der Open Source Seite noch 869 01:02:32,760 --> 01:02:37,500 nicht so. Aber wenn du in Enterprise Umgebungen unterwegs bist. Fast alle 870 01:02:37,500 --> 01:02:41,910 größeren Projekte sind alle irgendwie internetbasiert inzwischen. Selbst 871 01:02:41,910 --> 01:02:46,920 Appliances haben alle Internet, und das ist dann zu bestimmt 872 01:02:46,920 --> 01:02:52,050 60-80% Open Source, je nachdem, in welcher Branche man da unterwegs ist. Open 873 01:02:52,050 --> 01:02:55,980 Source hat einen großen Einblick, und als Open Source anfing zu sagen: "Okay, wir 874 01:02:55,980 --> 01:02:59,670 müssen agile werden", hat Enterprise nachgezogen. Daher, glaube ich, werden wir 875 01:02:59,670 --> 01:03:03,210 es schaffen, als Open Source hier Standards zu setzen, dass es auch in 876 01:03:03,210 --> 01:03:06,106 Enterprise rüberschwappt, das ist die Hoffnung... 877 01:03:06,818 --> 01:03:11,855 *36C3 Musik* 878 01:03:11,855 --> 01:03:40,000 Untertitel erstellt von c3subtitles.de im Jahr 2020. Mach mit und hilf uns!