Wie viel Security braucht es auf Sprachenniveau?

Auf dem dunklen Pfad: Programmiersprachen-Debatte um Kotlin & Swift

Hartmut Schlosser

(c) Shutterstock / andreiuc88

Wir begeben uns auf einen dunklen Pfad, wenn wir immer mehr Sicherheitsfunktionen in die Programmiersprachen selbst einbauen. Mit dieser These weist Robert C. Martin (alias Uncle Bob) die Sprachen Swift und Kotlin zurück. Laut Martin verführen solche Features Entwickler dazu, nicht mehr selbst für Risikominimierung zu sorgen.

Uncle Bob nennt drei Beispiele:

  1. Swift und Kotlin sind beides stark typisierte Sprache. Den Typisierungsregeln muss man strikt Folge leisten. Wer beispielsweise in Swift eine Funktion definiert, die eine Exception auswirft, muss jeden Funktionsaufruf mit einem do-try-Block, einem try! oder einem try? ausstatten.
  2. In Kotlin kann nicht von einer Klassen abgeleitet werden, ohne dass diese explizit als open deklariert wird. Genauso kann keine Funktion überschrieben werden, ohne dass die überschreibende Funktion mit einem override versehen wird.
  3. Sowohl Swift als auch Kotlin beinhalten das Konzept der nullable-types, d.h. die Option, dass eine Variable den Wert null annehmen kann, ist Teil des Types der Variable. Wenn man nun eine solche nullable Variable nutzt, muss sie notwendigerweise auf null überprüft werden.

In allen drei Fällen stellt Martin die Frage: Ist es wirklich sinnvoll, dass die Sprache selbst solche Fehlerquellen ausschaltet?

  • Sollte es in der Verantwortung der Sprache oder der Entwickler liegen, das Abfangen von Exceptions sicher zu stellen?
  • Sollte es in der Verantwortung der Sprache oder der Entwickler liegen, für korrekte Vererbungs- und Ableitungshierarchien zu sorgen?
  • Sollte es in der Verantwortung der Sprache oder der Entwickler liegen, null-Werte korrekt handzuhaben?

Auf dem falschen Weg?

Für Bob Martin weisen solche Features in eine falsche Richtung, denn man versuche, häufig auftretende Fehler der Software-Entwicklung auf Sprachniveau zu beheben. Eigentlich seien solche strengen Sicherheitsfunktionen lediglich eine Reaktion auf eine Nachlässigkeit beim Entwickeln: nämlich vernünftige Tests zu schreiben.

You test that your system does not emit unexpected nulls. You test that your system handles nulls at it’s inputs. You test that every exception you can throw is caught somewhere.

Das eigentlich Problem liegt laut Martin darin, dass Software-Programmierung ein Prozess ist, in dem sich Vieles erst beim Tun ergibt, Änderungen also an der Tagesordnung sind:

Consider: How do I know whether a class is open or not? How do I know if somewhere down the calling tree someone might throw an exception? How much code will I have to change when I finally discover that someone really needs to return a null up the calling tree?

Martins Argumentation: All diese starren Ketten, die Sprachen wie Swift und Kotlin um die Software-Entwicklung legen, setzen voraus, dass ein Programmierer voarb schon alles über sein System weiß. Da dies indes nicht so ist, wird ein Entwickler zunächst all die gut gemeinten Sicherheitsvorkehrungen überschreiben. Also werden alle Klassen und Funktionen als open deklariert, niemals Exceptions genutzt, null-Checks gänzlich vermieden.

Die guten Absichten verkehren sich in ihr Gegenteil: Die Sicherheit der Anwendungen sinkt.

Why did the nuclear plant at Chernobyl catch fire, melt down, destroy a small city, and leave a large area uninhabitable? They overrode all the safeties. So don’t depend on safeties to prevent catastrophes. Instead, you’d better get used to writing lots and lots of tests, no matter what language you are using!

Debatte

Der Blogpost hat in der Community eine rege Diskussion ausgelöst, wo die Grenze zwischen sprachlichen Sicherheitsfeatures und Sicherheitstests verlaufen sollte.

Wo würden Sie für sich selbst die Grenzen ziehen?

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.