Dependency hell

„That guy just broke the internet“ – gestern war es dann mal soweit, eine nicht mehr erfüllbare Abhängigkeit in der Welt des Javascript Paketmanagers npm sorgt dafür, dass eine unüberblickebare Zahl an „cutting edge“ Javascript-Anwedundungen den build verweigerte.

Was für manche nun ein worst case Szenario darstellt, würde ich mal eher als glücklichen Weckruf bezeichnen – es kam immerhin wohl niemand zu schaden. Viel mehr offenbart es jedoch ein grundsätzliches Problem mit dem Umgang von Abhängigkeiten in der Web-Entwicklung – egal ob nun Javascript, PHP, etc. Dabei sind es meist nicht die expliziten Dependencies, die Sorgen bereiten sondern die impliziten. Beim Hinzufügen einer Abhängigkeit würde ich zumindest erwarten, dass sich der Entwickler genau ansieht, was an Code er sich da gerade in sein Projekt reinhängt. Natürlich wird dies in den wenigsten Fällen ein gründliches Audit sein, jedoch reicht oftmals schon ein Blick auf den Code um eine Bewertung hinsichtlich Qualität und Sauberkeit abgeben zu können.

Nun ist es leider so, dass dieser Vorgang spätestens bei den Dependencies dieser Library/dieses Pakets aufhört. Wer macht sich schon ernsthaft die Arbeit, den kompletten Abhängigkeitsbaum von externen Libraries zu prüfen? Und das bei jedem Update der Komponente? Ganz recht, niemand. Hier kommt die „chain of trust“ ins Spiel – ich würde das auch als „Verantwortungsdelegation“ bezeichnen. Man geht davon aus, dass die Maintainer eines Projekt schon wissen was sie tun. Ergo spricht man sich direkt oder indirekt frei von der Verantwortung der Überprüfung, schließlich kümmert sich ja das Team der Library darum. In einer idealen Welt ist dies auch durchaus ein gangbarer Weg, nur werde ich nun niemanden irgendwas von perfekten Welten erzählen – die Realität sieht wie immer anders aus.

Diese „Vertrauenskette“ ist genau so stark wie sein schwächstes Glied. Es bedarf lediglich einer kleinen Änderung eines Pakets, welches sich irgendwo in der zweiten oder dritten Abhängigkeitsebene eines Projekts/einer Library befindet, um kaputten Code oder schlimmstenfalls Schadcode in zig Softwareprojekte einzuschleusen – ohne, dass es jemand merkt. Dabei spielt es keine Rolle, wie genau der Code in die kleine Subabhängigkeit gelangt, ob aus Unachtsamkeit, Absicht oder durch einen gehackten Github-Account. Dein Paketmanager unterstützt Versionierung? Kein Problem, einfach die Patch-Level Versionsnummer erhöhen und davon profitieren, dass dem Paketmanager gesagt wurde, Patch-Level Updates der Library blind zu übernehmen – wer möchte schon ein Audit bei jedem kleinen Bugfix-Release machen?

Es bleibt nur eins: Sich auf möglichst wenige Abhängigkeiten verlassen und vielleicht nicht für jeden Einzeiler-Code eine Abhängigkeit installieren. Die lebensnotwendigen Dependencies wenn möglich auf die Patch-Level Version festpinnen und jedes Update dieser Abhängigkeit genau prüfen. Das wird so manchem Hauruck-Hurra-Klicki-Bunti-Code-Zusammenklicker vielleicht nicht gefallen, ist aber der einzige Weg wie man so etwas wie „Stabilität“ in das eigene Projekt bringen kann.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s