Fragen? Antworten! Siehe auch: Alternativlos
Nein, muss es nicht. Im Gegenteil. Das wäre das Ende von Open Source.
Außerdem lässt es der Artikel so klingen, als habe sich jetzt herausgestellt, dass Open Source Software weniger gut als kommerzielle sei. Das ist ganz großer Unsinn (auch wenn es natürlich auf beiden Seiten Ausreißer gibt, die deutlich besser als der Durchschnitt der anderen Seite sind).
Open Source als Bewegung ist das Konzept, dass man Leute Code schreiben lässt, deren Herzensblut dranhängt. Die es eben nicht kurz herunterpfuschen, weil sie dafür bezahlt werden. Open Source ist die Beobachtung, dass manche Menschen es lieben, Code zu schreiben. Und wenn man sie nicht mit Deadlines und Deliverables und dem monatlichen Paycheck unter Druck setzt, dann nehmen sie sich die Zeit und machen ihr Projekt ordentlich. Viel ordentlicher jedenfalls als die durchschnittliche kommerzielle Software.
Inzwischen wird kommerzielle Software wie Open Source entwickelt. Weil das Modell funktioniert. Kaum eine Firma entwickelt heute noch Software ohne Unit Tests, ohne Source Code-Versionskontrolle, überall gibt es ein Wiki für die Dokumentation und alle wollen gerne agil sein.
Der Erfolg von Open Source war so durchschlagend, dass es das Gegenmodell gar nicht mehr in freier Wildbahn gibt!
Wenn es etwas gibt, das sich bei Open Source zu ändern lohnt, dann ist es der mangelnde Respekt. Nur weil du gerne Programmieren lernen willst, heißt das nicht, dass du am Linux-Kernel herumfummeln solltest. Deine eigene SSL-Library schreiben? Kein Ding. Tu es! Da kann es nur Gewinner geben, selbst wenn es niemals fertig wird und niemand deinen Code benutzt. Du hast dabei was gelernt und als Programmierer an Größe gewonnen. Ein wenig bekanntes Detail aus der OpenSSL-Genesis ist, dass das mal SSLeay hieß — eay sind die Initialen des initialen Autoren, Eric Young —, und der hat das Projekt gestartet, weil er lernen wollte, wie die Division von 1024-Bit-Zahlen funktioniert.
Der Kern des Problems ist aus meiner Sicht, dass wir als Gesellschaft uns darauf geeinigt haben, dass Software halt ein schwieriges Problem ist, und daher Fehler halt passieren und niemand für seine Fehler geradestehen muss. Man kann sich heute bei so gut wie allen Problemen mit "das war ein Softwarefehler" herausreden. Für mich als Programmierer ist das natürlich auf der einen Seite toll, weil ich mich so Dinge trauen kann, die ich sonst nicht in Angriff nehmen würde. Aber es hat in der Szene so ein wirklich widerliches Gefühl erzeugt, als hätten wir Programmierer es verdient, als sei das unser Recht, niemals für unseren Scheiß den Kopf hinhalten zu müssen. Ich will das mal anhand dieser Tweets veranschaulich. So tief sitzt da die Panik! So ein Affront für das Weltbild ist es, dass möglicherweise jemand kommen könnte, und der sieht, dass ich gepfuscht habe! Sowas finde ich zutiefst unwürdig. Als ob der Auditor Schuld hat, wenn dein Code Scheiße ist! Wenn bei einer Frittenbude Küchenschaben gefunden werden, ist dann das Gesundheitsamt der Bösewicht? Wenn GM kaputte Autos baut, und da sterben Leute, glaubt ihr auch, die Zuständigen machen sich in erster Linie Sorgen wegen der Hater aus dem Internet? Anders gefragt: Würde irgendjemand von euch von einer Firma kaufen, die nur Qualitätskontrolle macht, weil sie Angst vor Internet-Hatern hat, wenn herauskommt, wir ranzig ihr Produkt ist?!
Dass überhaupt das Wort "Hater" gefallen ist, sagt aus meiner Sicht schon alles. Wenn du etwas baust, dann sollte das der güldene Sonnenschein sein, nach frisch gebackenem Brot durften und die filigrane Eleganz eines mathematischen Beweises haben. Und zwar nicht weil es da draußen "Hater" gibt, sondern weil das dein verdammer Anspruch an dich selbst ist! Wenn jemand kommt und dich auf Fehler in deinem Code hinweist, dann solltest du auf die Knie fallen und dem Fremden überschwänglich danken, denn er hilft dir, deinen Code näher an die Zielvorstellung der Perfektion zu bringen!
Ich glaube nicht, dass bei Software so viel mehr gepfuscht wird als anderswo. Aber physische Dinge sind vergänglich. Fehler bei physischen Dingen gehen von alleine weg, mit den Dingen selbst. Software lebt theoretisch für immer. Softwarefehler akkumulieren immer nur. Aus meiner Sicht müssen wir Software wie radioaktiven Müll behandeln — vorsichtig und mit Bedacht.
Nachdem ich all das gesagt habe, möchte ich noch sagen: Schreibt mehr Software! Aber macht es ordentlich!
Update: Jetzt bin ich ganz von meinem eigentlichen Gedankengang abgekommen. Open Source funktioniert, weil es eben nicht geldgetrieben ist. Der Programmierer zieht seinen Anreiz, die Software zu schaffen, aus der kreativen Freude des Programmierens, und aus dem Zen-ähnlichen Zustand, wenn ein komplexer Algorithmus, den man hingeschrieben hat, dann tatsächlich funktioniert. Guter Code ist seiner selbst Belohnung. Wenn man dort Geld als Anreiz einbringt, dann wird das dieses Modell kaputtmachen. Programmierer werden dann anfangen, die Arbeit pro eingenommenem Euro zu minimieren. Genau wie das überall eintritt, wo man Geld für Arbeit zahlt. Am Ende wird man feststellen, dass die Stundenlöhne anderswo niedriger sind als bei uns, und dann wird niemand mehr in Deutschland Open Source programmieren wollen. Nur weil man das mentale Modell so umgebaut hat, dass wir das "für Geld" tun, nicht um etwas zu lernen, oder den anderen Gründen. Macht das bloß nicht!
Geld für Dinge ausgeben, bei denen niemand kreative Genugtuung erfährt, das kann man diskutieren. Ich glaube, das wird man auch machen müssen, damit auch bei den SSL-Libraries wieder Open Source qualitativ führend ist. Aber fangt nicht an, das Belohnungsmodell von Open Source Programmieren auf "da gibt es Geld für" umzustellen. Das wäre der Untergang.
Update: Ich will mal eine Kommentarmail hier zitieren:
In der Psychologie unterscheidet man zwischen extrinsischer und intrinsischer Motivation. Intrinsische Motivation bedeutet, dass man etwas tut, weil es einem Spass macht, weil man es für richtig hält etc. Extrinsische Motivation bedeutet, dass man etwas tut, weil man eine Belohnung dafür erhält. Sozialpsychologische Experimente haben gezeigt, dass man intrinsische Motivation unwiederbringlich zerstören kann, indem man einen extrinsischen Anreiz schafft, etwas zu tun.
Update: Noch eine Einsendung:
Die moderne Motivationsforschung sagt an dieser Stelle „Nein“, weil die Programmierer bereits in dem Moment wo sie Geld bekommen den Spaß verlieren würden, aus Spiel wird dann Arbeit. Das Ganze geht auf die Selbstbestimmungstheorie der Motivation von Deci & Ryan, 1985a zurück (s. Wikipedia). Lese grade Drive von Daniel Pink (ISBN 978-1847677686), was die gedankliche Grundlage für die agile Softwareentwicklung z.B. Scrum beschreibt. Bei modernen Softwareschmieden gehört diese Kenntnis mittlerweile auch zum Einstellungskriterium.
Die aktuelle Inkarnation war, dass die nervigen Selbstvermarkter von Cloudflare sich hingestellt haben, und behauptet haben, also in IHREM Setup käme man per Heartbleed aber nicht an die SSL-Zertifikate ran, daher müssten sie jetzt auch nicht alle zurückrufen und neumachen. Als Beweis haben sie eine Teststellung hingestellt, und das Internet herausgefordert, ihnen eine mit ihrem Schlüssel signierte Botschaft zu schicken. Hier ist ihre Challenge-Webseite.
Und siehe da: jemand hat den Key extrahiert.
Aber die Kernbotschaft, egal ab wann Geheimdienste das exploited haben, ist: Geheimdienste arbeiten gegen ihre eigene Bevölkerung, nicht für sie. Die Geheimdienste wussten davon und haben nichts gesagt.
Oh und eine Sache noch: Das sieht jetzt hier aus wie eine Bankrotterklärung von Open Source. Das stimmt nicht. Der Bug wurde von zwei Leuten gleichzeitig gefunden und gemeldet. Einmal von einer Security-Firma, die eine Testsuite für SSL-Bugs programmiert hat. Die hätte das auch bei einem Nicht-Open-Source-SSL gefunden. Aber der andere Finder war ein Google-Angestellter, der einen Quellcode-Audit gemacht hat. Den hätte es so bei einem Nicht-Open-Source-SSL nicht gegeben. Wir haben hier also die Chancen direkt verdoppelt, solche Bugs zu finden. Wer weiß, was in Kommerzsoftware noch so für Untiefen lauern.
Meiner Erfahrung nach variiert die Codequalität bei Open Source und bei kommerzieller Software immens, und der Durchschnitt liegt ungefähr auf einem vergleichbaren Niveau. Man kann nicht davon ausgehen, dass kommerzielle Software grundsätzlich ein höheres Niveau hat.
Übrigens stört mich an der Debatte ein bisschen, dass so wenig Leute daraus Konsequenzen ziehen. Wir benutzen alle die ganze Zeit Open Source Software, ohne dafür zu zahlen, und wir benutzen Kommerzsoftware und bezahlen dafür. Dann wundern wir uns, dass die Hersteller von Kommerzsoftware Geld haben, um davon Audits machen zu lassen, aber die Open Source-Leute warten müssen, bis Google mal vorbeikommt.
Eine mögliche Konsequenz aus dem aktuellen Geschehen könnte sein, dass man mal einen Fonds macht, in den Benutzer von Open Source-Software einzahlen, und mit dem dann Qualitätssicherungsmaßnahmen bezahlt werden, für die Freiwillige bei den jeweiligen Projekten nicht die Motivation aufbringen. Das meint natürlich Security-Audits, aber es meint auch sowas wie ordentliche Testsuiten basteln; Dokumentation bereitstellen.
Update: Die US-Regierung dementiert. Was sollen die auch sonst sagen. Sie behaupten sogar, dass sie alle Lücken reporten, die sie finden. Ja nee, klar.
Wir haben damals gesagt: Wenn ihr Exploits als Waffen bewertet und ihren Besitz unter Strafe stellt, dann hat das mehrere Auswirkungen:
Update: Die EFF zu dem Fall.
Ich möchte die Gelegenheit nutzen, nochmal darauf hinzuweisen, dass ich selbstverständlich nicht behauptet habe, Herr Seggelmann habe hier absichtlich eine Backdoor programmiert. Ich habe behauptet, dass er den Code programmiert hat. Dazu verlieh ich meiner Einschätzung Ausdruck, dass der Code wie eine Backdoor aussieht. Nicht dass es eine ist. Denn das kann man anhand des Codes auch gar nicht entscheiden, wie ich auch in dem FAZ-Artikel ausführe. Daher gibt es auch keine Grundlage für so eine Behauptung.
Update: Spon hat den Artikel umgeschaltet, und sie haben mir versichert, dass es nicht so gemeint war, wie es da stand. OK. Schwamm drüber.
Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets (Danke, Bjoern)
Hier ist der git commit. Das ist aber nicht der Punkt hier gerade.
Wo arbeitet der? Was meint ihr? Kommt ihr NIE drauf!
Robin Seggelmann T-Systems International GmbH Fasanenweg 5 70771 Leinfelden-Echterdingen DE
Update: Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.
Ich sehe in dem Code nicht mal den Versuch, die einkommenden Felder ordentlich zu validieren. Und auch protokolltechnisch ergibt das keinen Sinn, so eine Extension überhaupt zu definieren. TCP hat seit 30 Jahren keep-alive-Support. Es hätte also völlig gereicht, das für TLS über UDP zu definieren (und auch da würde ich die Sinnhaftigkeit bestreiten). Und wenn man ein Heartbeat baut, dann tut man da doch keinen Payload rein! Der Sinn von sowas ist doch, Timeouts in Proxy-Servern und NAT-Routern vom Zuschlagen abzuhalten. Da braucht man keinen Payload für. Und wenn man einen Payload nimmt, dann ist der doch nicht variabel lang und schon gar nicht schickt man die Daten aus dem Request zurück. Das ist auf jeder mir ersichtlichen Ebene völliger Bullshit, schon das RFC (das der Mann auch geschrieben hat), das ganze Protokoll, und die Implementation ja offensichtlich auch. Aus meiner Sicht riecht das wie eine Backdoor, es schmeckt wie eine Backdoor, es hat die Konsistenz einer Backdoor, und es sieht aus wie eine Backdoor. Und der Code kommt von jemandem, der bei einem Staatsunternehmen arbeitet, das für den BND den IP-Range betreut (jedenfalls vor ein paar Jahren, ob heute immer noch weiß ich nicht). Da muss man kein Adam Riese sein, um hier 1+1 zusammenzählen zu können.
Update: Es stellt sich raus, dass der Mann damals noch an seiner Dissertation geschrieben hat und an der Uni war und erst später bei T-Systems anfing. In der Dissertation geht es unter anderem um die Heartbeat-Extension, die mit UDP begründet wird. In dem Text steht auch drin, dass man keine Payload braucht. Aber lasst uns das mal trotzdem so machen, weil … Flexibilität und so!
Update: Echte Verschwörungstheoretiker lassen sich natürlich von sowas nicht aufhalten. Der Job bei T-Systems war dann halt die Belohnung!1!! Und echte Verschwörungstheoretiker googeln auch dem Typen hinterher, der den Code auditiert und durchgewunken hat, damit der eingecheckt werden konnte. Ein Brite, der nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt!!1!
Update: Robin Seggelmann hat der australischen Presse erklärt, das sei ein Versehen gewesen.
Update: Hier ist eine Gegendarstellung dazu von Herrn Seggelmann:
Der Fehler ist ein simpler Programmierfehler gewesen, der im Rahmen eines Forschungsprojektes entstanden ist. T-Systems und BND oder andere Geheimdienste waren zu keiner Zeit beteiligt und zu meiner späteren Anstellung bei T-Systems bestand zu keiner Zeit ein Zusammenhang. Dass T-Systems im RFC genannt wird, liegt an der verspäteten Fertigstellung des RFCs und es ist üblich, den bei der Fertigstellung aktuellen Arbeitgeber anzugeben.
(Danke, Jürgen)
Affiliate-Information
Bei den mit gekennzeichneten Links handelt es sich um Provisions-Links (Affiliate-Links). Erfolgt über einen solchen Link eine Bestellung, erhält Fefe Shoppingempfehlungen SRL eine Provision. Für den Käufer entstehen dadurch keine Mehrkosten.