„Memory Safe“ Programmiersprachen
Ja. Da haben sie recht.
Sogar das Weiße Haus, die US-Regierung mahnt inzwischen dazu, „memory safe“ Programmiersprachen zu verwenden: Weißes Haus rät und ermahnt: Verzichtet auf Sprachen wie C und C++
Das ist zwar nicht unbedingt deren Aufgabe, aber wo sie recht haben, haben sie recht.
Konkret hat das White House Office of the National Cyber Director (ONCD) einen Bericht (PDF) veröffentlicht (via Infoworld), in dem man Entwicklern nahelegt, “speichersichere Programmiersprachen” zu verwenden – und dazu zählen C und C++ eben nicht. Laut ONCD können IT-Unternehmen mit der Einführung speichersicherer Programmiersprachen verhindern, “dass ganze Klassen von Schwachstellen in das digitale Ökosystem eindringen”.
Ja, das sage ich ja auch schon lange. Mich nervt das ja auch, dass wir seit „With Microscope and Tweezers“ von 1988 eigentlich nichts dazugelernt haben, und der Haufen Schrott immer nur immer größer wird.
Und ja, jedesmal, wenn ich das erwähne, bekomme ich einen Haufen Zuschriften, dass man in modernem C++ auch speichersicher programmieren kann.
Leute, das ist bullshit. Wenn man es kann, es aber davon abhängt, dass man es will und bewusst macht, dann ist es eben nicht „memory safe“.
Zwar fressen die Speichertests Rechenzeit, und man kann ja argumentieren, dass die Indexvariable aus Gründen des Programmlaufs im richtigen Bereich sein muss, aber die Erfahrung zeigt eben, dass das in der Praxis nicht so ist und da die meisten Fehler lauern. Vielleicht schön, dass man es kann, aber das Ergebnis ist halt viel zu oft Murks.
Früher, ganz früher, habe ich mal sehr viel in C und C++ programmiert. Ich habe C++ mal so richtig durchbeherrscht. Nur: Ich habe neulich mal versucht, mich auf den aktuellen Stand bei C++ zu bringen und bin schlicht gescheitert. Es war nicht möglich, eine aktuelle Beschreibung der Sprache zu finden, und Bücher werden dazu kaum noch geschrieben. Eine Sprache, deren Beschreibung man nicht mehr auf einfache Weise finden kann, ist ohnehin nicht mehr brauchbar.
Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®
[…]
Memory issues in software comprise a large portion of the exploitable vulnerabilities in existence. NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. Memory safe languages provide differing degrees of memory usage protections, so available code hardening defenses,
such as compiler options, tool analysis, and operating system configurations, should be used for their protections as well. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit.
Ja.
Wobei ich sagen muss, dass ich auch davon keine Sprache so wirklich gut finde. Ruby gefällt mir sehr gut und ist sehr elegant, effektiv, was das Programmieren angeht, aber als Interpretersprache sehr langsam und die fehlende Typbindung macht das sehr, sehr fehleranfällig. Java ist eine Katastrophe für sich. Go ist zu primitiv. Rust ist beeindruckend, aber noch nicht so ganz ausgereift, außerdem stört mich, dass sie eine zu niedrige Programmiersprache ist und keine Objektorientierung hat, und mitunter sehr sperrig ist.
Das Problem ist, dass ständig irgendwer mit einer neuen Programmiersprache um die Ecke kommt und ständig irgendwo irgendwer irgendein Steckenpferd implementieren will. Aber jedesmal, wenn einer sagt, dass die bestehenden Sprachen alle Mist sind und er jetzt das Ei des Kolumbus gefunden hat, wächst der Misthaufen nur von n auf n+1. Deshalb gibt es viele schlechte, aber keine richtig gute Sprachen, weil sich das viel zu sehr diversifiziert und es heute ganz wichtig ist, dass man die Rechte daran hält (wenn ich das schon sehe, dass sie die Sprachen mit ® und ™ auflisten), deshalb jeder Laden seine eigene Sprachen haben will und muss.
Grausig.
Und vor allem problematisch, weil derzeit nur Bibliotheken, die in C oder C++ geschrieben sind, in viele andere Sprachen eingebunden werden können, und es effektiv unmöglich ist, all die bestehenden Bibliotheken in all die Sprachen umzuschreiben. Irgendwie alles gerade Krampf.