Das npm-faker-Paket und das unerwartete Ende von Open-Source-Bibliotheken

Wohin verschwinden Open-Source-Abhängigkeiten, und warum werden sie eingestellt? Was ist mit dem npm-faker-Modul passiert? Kann sich das wiederholen? Erfahren Sie mit mir, wie Open-Source-Softwarebibliotheken zu Ruhm gelangen und wie sie ihr Lebensende erreichen. Außerdem gebe ich Entwicklern und Ops Engineers einige Tipps mit auf den Weg.

Ich möchte einige Geschichten aus dem JavaScript- und PHP-Ökosystem erzählen. Sie handeln von abrupten Störungen der Software-Supply-Chain aufgrund von Klima- und Umweltbedenken sowie von Rechtsstreitigkeiten im Zusammenhang mit Politik und humanitären Aktionen.

• Die JavaScript-Bibliothek left-pad und der npm-Maintainer Azer Koçulu

• Die Faker-Bibliothek für PHP, Laravel und andere Projekte zur Generierung von Testdaten

• Die npm-Faker-Bibliothek

Im Mittelpunkt unserer Geschichten stehen Protestware-Bewegungen im Open-Source-Bereich, die aufgrund verschiedener Fragen rund um die Nachhaltigkeit von Open Source, den Klimawandel und die Freiheit von Open-Source-Software entstanden sind.

Eine weitere interessante Geschichte über Protestware auf npm dreht sich um den Maintainer eines node-ipc-npm-Pakets, der aufgrund einer politischen Krise Maßnahmen ergriff.

Die JavaScript-Bibliothek left-pad und der npm-Maintainer Azer Koçulu

Dies ist die Geschichte darüber, wie rechtliche Schritte eines Unternehmens gegen einen Open-Source-Entwickler dazu führten, dass Tausende von Projekten im JavaScript-Ökosystem nicht mehr funktionierten, darunter Node.js und Babel. €‹ €‹

Azer Koçulu, Maintainer des left-pad-npm-Pakets, betreute ein weiteres npm-Modul namens Kik. Offenbar erregte das Kik-Modul die Aufmerksamkeit von Unternehmensanwälten, weil es eine gleichnamige Instant-Messaging-App gab. Trotz der Kommunikation mit den Anwälten und der Aufforderungen von npm weigerte sich Azer, das Paket umzubenennen.

Angesichts der Androhung einer Klage (und weil die npm-Organisation keine Einigung zwischen beiden Seiten erzielen konnte) entfernte Azer mehr als 250 seiner npm-Pakete aus der npm-Registry – als Zeichen des Protests.

Eines dieser npm-Pakete war leider left-pad. Was ist left-pad? Left-pad ist eine winzige Bibliothek mit 17 Codezeilen zum Auffüllen von Strings mit Leerzeichen, wenn man sich auf left-pad@1.0.0 bezieht. Doch selbst beim Auffüllen eines Strings müssen Sonderfälle berücksichtigt werden. Die neueste Version, 1.3.0, wurde am 9. April 2018 wie folgt veröffentlicht:

1/* This program is free software. It comes without any warranty, to
2     * the extent permitted by applicable law. You can redistribute it     * and/or modify it under the terms of the Do What The Fuck You Want
3     * To Public License, Version 2, as published by Sam Hocevar. See
4     * http://www.wtfpl.net/ for more details. */'use strict';
5module.exports = leftPad;
6
7var cache = [
8  '',
9  ' ',
10  '  ',
11  '   ',
12  '    ',
13  '     ',
14  '      ',
15  '       ',
16  '        ',
17  '         '
18];
19
20function leftPad (str, len, ch) {
21  // convert `str` to a `string`
22  str = str + '';
23  // `len` is the `pad`'s length now
24  len = len - str.length;
25  // doesn't need to pad
26  if (len <= 0) return str;
27  // `ch` defaults to `' '`
28  if (!ch && ch !== 0) ch = ' ';
29  // convert `ch` to a `string` cuz it could be a number
30  ch = ch + '';
31  // cache common use cases
32  if (ch === ' ' && len < 10) return cache[len] + str;
33  // `pad` starts with an empty string
34  var pad = '';
35  // loop
36  while (true) {
37    // add `ch` to `pad` if `len` is odd
38    if (len & 1) pad += ch;
39    // divide `len` by 2, ditch the remainder
40    len >>= 1;
41    // "double" the `ch` so this operation count grows logarithmically on `len`
42    // each time `ch` is "doubled", the `len` would need to be "doubled" too
43    // similar to finding a value in binary search tree, hence O(log(n))
44    if (len) ch += ch;
45    // `len` is 0, exit the loop
46    else break;
47  }
48  // pad `str`!
49  return pad + str;
50}

Left-pad wurde mehr als 2,5 Millionen Mal im Monat heruntergeladen und war damit sehr beliebt. Das Zurückziehen von left-pad führte dazu, dass andere davon abhängige Projekte nicht mehr funktionierten: Node.js, Babel und weitere (mehr dazu unter http://left-pad.io/).

Die Folgen des Zurückziehens von Abhängigkeiten aus der npm-Community waren ein Novum in der npm-Registry. Niemand hätte gedacht, dass jemand so etwas tun würde.

Dies wurde als die Geschichte bekannt, wie ein einzelner Entwickler mit 17 Codezeilen das JavaScript-Ökosystem lahmlegte.

Wie füllt man in JavaScript einen String links auf?

Der String-Prototyp umfasst die Methoden padStart() und padEnd(). Sie erwarten zwei Argumente: die Zeichenlänge, auf die aufgefüllt werden soll (pad), und den String, mit dem aufgefüllt wird (pad with). Zurückgegeben wird der neu aufgefüllte String. Diese API ist ab Node.js 8 verfügbar und wird derzeit von allen modernen Browsern unterstützt.

Das folgende Codebeispiel zeigt, wie ein String in JavaScript links aufgefüllt wird:

1const someString = ‘h’;
2console.log(someString.padStart(5, 'h'));
3
4// output will be:
5####

Viele würden die Aufnahme dieser neuen ECMAScript-Spezifikation dem npm-Paket left-pad zuschreiben, weil es die Diskussion über eine umfangreichere Sprach-API angestoßen hat.

Die Faker-Bibliothek für PHP, Laravel und andere Projekte zur Generierung von Testdaten

Wären Sie bereit, ein erfolgreiches Projekt aufzugeben, wenn Sie dadurch Ihre Umweltbilanz verbessern könnten? In dieser nächsten Geschichte geht es um einen Maintainer, der mutig genug war, seinen Erfolg zurückzustellen, wenn das zu einer grüneren Erde beitragen würde.

Lernen Sie François kennen. 2011 veröffentlichte François Zaninotto Faker, eine PHP-Bibliothek zur Erstellung von Testdaten, die sich für das Befüllen von Datenbanken und für Tests eignen.

Faker wuchs mit der Zeit und wurde sehr beliebt. Es gab SDKs in anderen Sprachen, etwa Python, und Unterstützung für mehr als 70 Gebietsschemata. Faker ist jedoch eine monolithische Bibliothek: Selbst wenn Sie für Ihre Tests nur einen Teil der Datensätze benötigen, um Benutzernamen zu simulieren, müssen Sie den gesamten Datensatz herunterladen – immerhin 3 MB.

Die meisten verwenden allerdings nur ein Gebietsschema. Wie groß war die Bibliothek? Die Faker-Bibliothek war etwa 3 MB groß. Für eine Entwickler-Tooling-Bibliothek ist das vielleicht nicht wenig, aber auch nicht besonders viel (denken Sie etwa an Chrome für E2E-Tests). Doch 2019 war Faker so beliebt, dass die Bibliothek im Laufe ihrer Lebenszeit mehr als 121 Millionen Mal heruntergeladen worden war.

Dazu eine Frage: Wie oft haben Sie sich schon Gedanken über die Größe einer Bibliothek gemacht (abgesehen von den offensichtlichen Optimierungen der Frontend-Performance)? Im Laufe der Jahre hat Faker wahrscheinlich mehr als 11 Tonnen CO2-Äquivalent ausgestoßen.

François wollte das nicht auf seinem Gewissen haben, deshalb wird das Projekt nicht mehr weitergeführt. Aber François hätte es doch an jemand anderen übergeben können, oder? François hatte mit einer früheren Bibliothek, die er entwickelt hatte, schlechte Erfahrungen gemacht: Properl, einer ORM-Bibliothek für PHP. Das hatte für ihn nicht funktioniert.

Damit ist die Geschichte der Faker-PHP-Bibliothek erzählt. Das Repository des Projekts auf GitHub wurde archiviert. Es gibt keine neuen Releases und keine neuen Pull Requests. Wie bei Open Source üblich, kann man den Quellcode eines Projekts jedoch forken. Entwickler boten an, Faker in eine neue Organisation mit neuen Maintainerinnen und Maintainer zu überführen. Das hätte jedoch bedeutet, den Ruf des Projekts in der Open-Source-Welt zu verlieren (zum Beispiel durch das Löschen der GitHub-Star-Bewertungen). Deshalb kam es nicht dazu.

François schrieb eine abschließende Nachricht an neue Maintainer und Entwickler: „Wenn Sie Interesse haben, können Sie mit einem Fork von Faker anfangen. Das wird viel besser sein als Faker. Seien Sie sich nur bewusst, dass Sie es in ein paar Jahren wahrscheinlich bereuen werden ;)“.

Die npm-Faker-Bibliothek

Diese Faker.js-Bibliothek hilft ebenfalls dabei, große Mengen zufälliger Daten zu generieren, die Sie in Ihren Tests verwenden können. Ihre Geschichte unterscheidet sich jedoch deutlich von der oben beschriebenen PHP-Bibliothek.

„Keine unbezahlte Arbeit mehr“, schrieb Marak Squires im November 2020 in einem GitHub-Issue zu einem seiner Repositories.

Die Pflege von Open-Source-Software ist eine große Belastung. Die Arbeit reicht vom Programmieren über die regelmäßige Projektpflege (einschließlich Dokumentation) bis hin zur Veröffentlichung von Releases, Aktualisierung von Changelog-Dateien, Schaffung eines einladenden Umfelds für neue Entwickler und Mitwirkende, Beantwortung von Fragen, Untersuchung gemeldeter Probleme und Überprüfung von Pull Requests. Das sind nur einige der Aufgaben, die für die Pflege eines gesunden Open-Source-Projekts anfallen.

Viele von uns Entwicklern und auch gewinnorientierte Unternehmen nutzen zweifellos eine Menge Open-Source-Software. Aber geben wir auch etwas zurück?

Marak ist ein Open-Source-Entwickler und Maintainer einiger Open-Source-Projekte. Er betreut ein beliebtes Open-Source-npm-Paket namens faker.js, das zeitweise mehr als zwölf Millionen Downloads pro Monat verzeichnete. Verwechseln Sie diese Geschichte jedoch nicht mit der vorherigen über die Faker-PHP-Bibliothek. Es handelt sich um unterschiedliche Projekte mit unterschiedlichen Maintainerinnen und Maintainer und unterschiedlichen Geschichten.

Maraks Arbeit unterstützte Entwickler in Fortune-500-Unternehmen bei ihrer Arbeit und trug letztlich zum Wachstum dieser Unternehmen bei. Doch wie viele Maintainer hatte er selbst wenig davon. Die Arbeit von Maintainerinnen und Maintainer ist größtenteils unbezahlt und wird kaum gewürdigt.

Im November 2020 beschloss Marak, ein Zeichen für die Nachhaltigkeit von Open Source – oder deren Fehlen – zu setzen. Der Maintainer eröffnete ein Issue in seinem GitHub-Repository und erklärte, dass er keine unbezahlte Arbeit mehr leisten werde.

Gemessen an den Emoji-Reaktionen auf Maraks Aussage in diesem GitHub-Issue wurde sie von der Community weitgehend akzeptiert und anerkannt. Marak wurde gehört, doch seine Aktionen hinterließen keinen nennenswerten bleibenden Eindruck.

Am 5. Januar 2022 veröffentlichte der Maintainer eine neue Version des Faker.js-npm-Pakets mit der semantischen Versionsnummer 6.6.6. Damit ist faker@6.6.6 eine gültige Version, die aus der npm-Registry heruntergeladen werden kann.

In der neuen Version 6.6.6 wurden alle Spuren des ursprünglichen Quellcodes des Faker.js-npm-Pakets vollständig entfernt. Jede neue Installation dieser neuen Hauptversion hätte dazu geführt, dass die Funktionalität nicht mehr funktioniert.

Zusätzlich zur Veröffentlichung der neuen Version faker@6.6.6 als Teil dieser Aussage wurde auch ein Commit per Force-Push in das Faker.js-GitHub-Repository übertragen, der den gesamten Quellcode entfernte:

Wie stark würde ein defektes npm-Paket seine Nutzer beeinträchtigen? Um das einzuschätzen, müssen Sie verstehen, wie die Versionierung von npm-Paketen und der npm-Paketmanager normalerweise funktionieren.

Kurz gesagt: Wenn Sie faker bereits in Ihren Projekten verwenden, ruft der npm-Paketmanager die neueste Version ab – unabhängig davon, ob Sie Ihre Abhängigkeiten mit einer Lockdatei festlegen. Grundlage dafür sind die Auflösungen für Minor- oder Patch-Versionen. Sie bleiben dadurch jedoch innerhalb der „sicheren Zone“ der aktuellen Hauptversion von Faker.js. Denn faker@5.5.3 ist die neueste sichere Hauptversion. Für ein Upgrade auf die defekte Hauptversion faker@6.6.6 ist ein ausdrückliches Upgrade erforderlich, das Endnutzern oft nicht automatisch angeboten wird.

Vielleicht wollte dieser Maintainer also ein Zeichen setzen, aber niemand bekam die Folgen tatsächlich zu spüren? Die Geschichte geht weiter: Marak fügte dem colors-npm-Paket eine integrierte Denial-of-Service-Schwachstelle hinzu, die etwa hundert Millionen Downloads pro Monat betraf.

Tipps für den verantwortungsvollen Einsatz von Open-Source-Bibliotheken

Im Folgenden finden Sie vier praktische Empfehlungen für den Umgang mit Open-Source-Software, mit denen Sie die Sicherheitsrisiken durch Protestware-npm-Pakete und nicht mehr gepflegte Software vermeiden können.

1. Verwalten Sie Ihre Open-Source-Bibliotheksinfrastruktur effizient

Was können wir als Entwickler tun, wenn wir auf die Verfügbarkeit von Open-Source-Bibliotheken angewiesen sind? Pakete erneut aus Registries zu installieren, ist ineffizient und langsam und kann zu nicht deterministischen Ergebnissen führen.

Um besser mit Fällen umzugehen, in denen Pakete und Open-Source-Bibliotheken veraltet oder aus offenen Registries wie npm, PyPI und anderen entfernt werden, empfehlen wir lokale private Caching-Proxys wie das Open-Source-Projekt Verdaccio. Wir haben Juan Picado, den Maintainer von Verdaccio, interviewt. Lesen Sie das Interview, um mehr über die Verwaltung Ihrer Open-Source-Bibliotheken zu erfahren.

2. Prüfen Sie Open-Source-Bibliotheken sorgfältig

Wenn Sie neue Open-Source-Pakete einführen oder Alternativen zu bestehenden Paketen erwägen, nehmen Sie sich Zeit, die Community rund um das Projekt, seine bisherige Pflege und aktuellen Aktivitäten sowie seine Sicherheitslage zu bewerten. Auch weitere Aspekte sind wichtig, etwa die Qualität des Projekts und ob Tests und verfügbare Dokumentation vorhanden sind.

Ein Tool, mit dem Entwickler die Qualität von npm-Paketen beurteilen können, ist Snyk Advisor – eine hilfreiche, kostenlose Ressource, die verschiedene Aspekte eines Open-Source-Pakets messbar macht. Snyk Advisor gibt beispielsweise eine Bewertung des Zustands des nodemon-npm-Pakets ab.

3. Legen Sie Abhängigkeiten mit einer Lockdatei fest

Mit einer Lockdatei Abhängigkeiten auf bekannte und getestete Versionen festzulegen, ist eine gute Möglichkeit, deterministische Installationen zu erzielen. Das gilt unabhängig vom JavaScript-Ökosystem und ist eine bewährte Methode, um Überraschungen in CI und anderen Umgebungen zu vermeiden.

Wenn Sie noch keine Lockdateien verwenden und unsicher sind, wie sie funktionieren, empfehle ich Ihnen die Lektüre von Was ist eine package-lock.json?, um die Bedeutung und Funktionsweise der Abhängigkeitsverwaltung zu verstehen.

4. Legen Sie transitive Abhängigkeiten fest

In bestimmten Situationen können Sie die Version transitiver Abhängigkeiten, die Ihrem node_modules-Verzeichnisbaum hinzugefügt werden, möglicherweise nicht kontrollieren. Das liegt daran, dass diese Abhängigkeiten Teil anderer Abhängigkeiten sind, die von anderen Maintainerinnen und Maintainer festgelegt wurden.

Allerdings bieten npm und andere Paketmanager wie yarn oder pnpm eine Möglichkeit, die Version einer verschachtelten Abhängigkeit zu überschreiben, indem Sie den zulässigen Versionsbereich in Ihrer package.json-Datei angeben.

Hier ein Beispiel, das nach den Folgen der Sabotage des peacenotwar-Moduls und des Protestwares im npm-Paket node-ipc besonders wichtig war:

1"overrides": {
2    "node-ipc@>9.2.1 <10": "9.2.1",
3    "node-ipc@>10.1.0": "10.1.0
4  }

Abschließende Worte

Die Sicherheit von Open-Source-Software und Aktivismus liegen mir besonders am Herzen. Dieser Blogbeitrag basiert auf einem Vortrag, den ich im Mai 2022 auf der Cloud Native SecurityCon in Valencia gehalten habe. Wenn Sie interessiert sind, können Sie sich hier die Aufzeichnung ansehen:

Play Video: The Unexpected Demise of Open Source Libraries - Liran Tal, Synk

Ich empfehle außerdem dringend, proaktiv für die Sicherheit Ihrer Open-Source-Abhängigkeiten zu sorgen, indem Sie Ihre Git-Repositories mit Snyk verbinden. So erhalten Sie automatisierte Sicherheitskorrekturen und Upgrades der Abhängigkeitsversionen.