[English]Da deutet sich eine größere Sache im Bereich Open Source an. Tausende Projekte, die die Open Source-Module colors.js und faker.js über den Paketmanager npm eingebunden haben, sind jetzt in ein fettes Problem gelaufen. Denn die Nutzerschaft, die Software einsetzt, die auf diese Module angewiesen ist, steht vor nicht mehr funktionierenden oder abstürzenden Programmen. Die Vermutung, dass die betreffenden NPM-Bibliotheken kompromittiert worden sind, stellte sich als falsch heraus. Vielmehr baute der Entwickler dieser Bibliotheken absichtlich eine Endlosschleife in den Code ein. Der Grund: Frust, dass sich Mega-Konzerne und kommerzielle Nutzer von Open-Source-Projekten an dieser kostenlosen Bibliothek bedienen, ohne etwas zurück zu geben.
Anzeige
Kleine Einordnung
npm (Node Package Manager) ist ein Paketmanager für die JavaScript-Laufzeitumgebung Node.js. npm wurde 2010 von Isaac Schlueter als Mitarbeiter der kalifornischen Cloud-Plattform-Anbieters Joyent programmiert. Über npm werden Javascript-Pakete verteilt. Die Wikipedia merkt an, dass die npm Registry, wie jedes Repository dafür anfällig ist, dass Pakete mit Schadcode eingestellt werden. Werden solche Pakete via Abhängigkeiten in einem Softwareprojekt verwendet, können verschiedenste Supply-Chain-Angriffe ausgeführt werden. In der Vergangenheit wurden Attacken via Typosquatting und Social Engineering bekannt.
Die colors.js-Bibliothek wird allein auf npm über 20 Millionen Mal pro Woche heruntergeladen und fast 19.000 Projekte verwenden diese Bibliothek. Faker.js wird wöchentlich über 2,8 Millionen Mal auf npm heruntergeladen und hat über 2.500 Abhängigkeiten. Da basieren also sehr viele Projekte auf diesen beiden Komponenten.
Der Entwickler hat die Faxen dicke
Im November 2020 hatte der Entwickler von colors.js und faker.js, der Entwickler Marak Squires, gewarnt, dass er die großen Unternehmen nicht länger mit seiner "kostenlosen Arbeit" unterstützen werde und dass kommerzielle Unternehmen in Betracht ziehen sollten, entweder die Projekte zu forken oder den Entwickler mit einem sechsstelligen Jahresgehalt zu entschädigen.
… und nun hat es geknallt
Hat aber wohl wenig gefruchtet, denn am Wochenende tauchten plötzlich im Web Berichte auf, dass die npm-Bibliotheken, die die beiden genannten JS-Module verwenden, kompromittiert sein könnten. Auf GitHub gibt es für AWS einen Issue-Eintrag, der sich beklagt, dass beim Einbinden des cdk (Amazon Development Kit) per pnpm in node.js 16.3.0 nur noch nachfolgende Ausgabe erfolge:
Anzeige
Der nachfolgende Tweet greift dies auf und zeigt auch einen Screenshot der Ausgaben. Dort wird von einem Bug in colors.js gesprochen.
Die Kollegen von Bleeping Computer weisen in nachfolgendem Tweet darauf hin, dass es geknallt habe und beschreiben das gesamte Ausmaß in diesem Beitrag.
Es war kein Hack oder Angriff, sondern der Entwickler Marak Squires hat schlicht ein neues Commit durchgeführt und ein american flags-Modul in v1.4.44-liberty-2 hinzugefügt, welches die Ausgaben erzeugt.
Gleiches passierte für faker.js und der Entwickler postete hier für colors.js den Hinweis "It's come to our attention that there is a zalgo bug in the v1.4.44-liberty-2 release of colors", und das man an einer Lösung arbeite.
Der Grund für diesen Winkelzug seitens des Entwicklers scheint, so Bleeping Computer, eine Vergeltungsmaßnahme gegen Megakonzerne und kommerzielle Nutzer von Open-Source-Projekten zu sein. Diese greifen in großem Umfang auf kostenlose und von der Gemeinschaft betriebene Software zurück, geben aber nach Ansicht des Entwicklers nichts an die Gemeinschaft zurück.
Die README für das GitHub-Repository mit der modifizierten faker.js-Bibliothek enthält nun den Text "What really happened with Aaron Swartz?".
Aaron Hillel Swartz war ein US-amerikanischer Programmierer, Unternehmer, Autor, Organisator politischer Bewegungen und Hacktivist; bekannt vor allem als Mitgründer von Reddit und für seinen Einsatz gegen Internetzensur. Am 19. Juli 2011 wurde Swartz angeklagt, 4,8 Millionen wissenschaftliche Artikel von dem Zeitschriftenarchiv JSTOR illegal heruntergeladen zu haben. Er wollte diese Dokumente öffentlich zugänglich machen.
Nachdem Swartz die Daten an JSTOR ausgehändigt hatte, kündigte der Betreiber an, keine zivilrechtlichen Ansprüche gegen Swartz zu stellen. Der Fall wurde vom Staatsanwalt Stephen Heymann weiterverfolgt (Swartz drohten 35 Jahre Haft). Noch vor Beginn des Gerichtsprozesses, der für April 2013 angesetzt war, beging Swartz, der seit Jahren an Depressionen litt, Suizid.
GitHub hat das Konto des Entwicklers gesperrt (siehe diesen Tweet vom 6. Januar 2021) und NPM hat die Bibliotheken auf den vorherigen Stand zurückgerollt, so dass die abhängigen Pakete wieder funktional in die Projekte eingebunden werden. Die ganze Aktion war ein Warnschuss und hat eine Diskussion in der Open Source-Szene ausgelöst. Der Fall zeigt, auf welch wackeligen Füßen viele Projekte stehen – und ein Lieferkettenangriff könnte erneut Schockwellen durch die IT schicken. Im Grunde brauchen wir aber nicht über Supply-Chain-Attacks zu diskutieren, denn die Episode zeigt, wie kaputt der gesamte Prozess der Software-Entwicklung ist. Weitere Details könnt ihr bei Bedarf bei den Kollegen hier nachlesen.
Auf Twitter ist inzwischen diese Diskussion um die Person des Entwicklers entbrannt. Zu diesem Thema kann ich nichts sagen, zumal es wenig Web-Treffer zu den dort aufgeworfenen Stichworten gibt – im dümmsten Fall ist es eine Person gleichen Namens. Ist im Kontext des obigen Artikels auch nicht relevant, da es dort eher um Fragen "wie halten wir es mit FOSS in Bezug auf Multi-Millionen-Dollar-Firmen, die das kostenlos ausnutzen?" und "wie kann ein einzelner Entwickler Tausende node.js-Projekte ans Wackeln bringen?" geht.
Ähnliche Artikel:
Problem Dependency Hijacking in der Software-Entwicklung; Microsoft erneut betroffen
Staatliche Hacker aus Nordkorea zielen auf die IT Supply Chain
Codecov-Tool gehackt – Entwickler-Zugangsdaten wohl abgezogen
Vier Sicherheitsanbieter bestätigen SolarWinds-Vorfälle
Operation NightScout: Supply-Chain-Hack zielt auf Online-Gaming in Asien
Supply-Chain-Angriff auf Vietnams Zertifizierungsstelle
Anzeige
Verstehe ich nicht…
Entweder die kommerziellen Anwender dürfen diese Open Source Software kostenlos nutzen (das ist zwar fast immer so, aber nicht zwangsweise), dann darf er sich nicht beschweren, oder die Nutzung ist kostenpflichtig, dann soll er die Lizenzgebühr dafür einfordern. Aber Software zur Verfügung zu stellen, die auch kommerziell kostenlos genutzt werden darf und dann bei durchschlagendem Erfolg mit erspresserischen Maßnahmen nach einem sechsstelligen Jahresgehalt zu schreien, finde ich äußerst schräg.
Juristisch betrachtet hast Du recht. Eine wesentliche gedankliche, oder meinetwegen auch: ideologische, Basis von Open Soure ist allerdings, dass nicht die einen nur produzieren und die anderen nur konsumieren, sondern eine Gemeinschaft entsteht, in der alle zum Wohle aller beitragen. Sei es durch Mit-Entwicklung, durch Dokumentation, durch Bug-Reporting, oder eben finanziell.
Ich, der ich als Privatperson, wie viele andere auch, den von mir genutzten Open Source Projekten immer mal wieder kleinere Beträge zukommen lasse, sofern die das nicht durch ausschliessliches Anbieten von Paypal als Zahlungsmethode unmöglich machen, kann den Frust des Entwicklers daher durchaus verstehen.
Da hätte der "Gute" aber vorher dran denken sollen und hätte seinen Code nicht unter die MIT gestellt, sondern hätte besser eine andere Lizenz gewählt!
So ist es Sabotage und Erpressung!
Das sind Straftaten und wenn es blöd für ihn aus geht, wird er zu Recht dafür verknackt.
Ja. Das meinte ich mit dem "juristisch" (ohne selbst Jurist zu sein).
Aber obwohl ich das konkrete Vorgehen genauso bedenklich finde wie Du, kann ich den Ärger, der dazu geführt hat, schon verstehen. Ist so, wie wenn Du immer andere zum Essen einlädtst, ohne je ein "Danke" zu hören oder gar mal eine Gegeneinladung zu bekommen. Juristisch einwandfrei, aber trotzdem nicht schön.
Der "Gute" darf mit seinem Projekt machen was er möchte. Offensichtlich hatte er seine Gründe gehabt, diesen Weg zu gehen. Kann ich verstehen. Hätte er aber auch anders lösen können, indem er eine andere Lizenz gewählt hätte. Die Schuld sehe ich jedoch bei den großen Konzernen, die alles kostenlos wollten und einem dafür noch einen Arschtritt verpassen, dass sie damit Geld machen. Solche Konzerne sollten in Zukunft vielleicht alles selbst entwickeln. Vielleicht kommt dann ein Umdenken.
Auch frage ich mich, wieso denn die Entwickler der anderen Projekte nicht getestet haben und sich blind verlassen haben. Und haben die kein Backup? Wenn so etwas derartige Auswirkungen haben kann, stimmt auch was am System nicht!
ABER natürlich kann er nicht mit "seinem" Projekt machen, was er will.
Der Code ist öffentlich und somit steht es jedem frei, die entsprechenden Dateien zu kompilieren, was einige der "Großen" wahrscheinlich auch machen werden.
Nur was hat es ihm gebracht? Niemand wird jemals noch "Code" von ihm haben wollen. Und juristisch wird er auch noch belangt werden,
denn er hat gegen die MIT-Lizenz verstoßen.
> … denn er hat gegen die MIT-Lizenz verstoßen.
Möglicherweise hat er gegen die Nutzungsbedingungen der Webseite verstoßen, wo er den Code hochgeladen hat.
Aber ein Urheber (Programmierer, Buchautor, Musikkomponist, Fotograf …) ist prinzipiell nicht verpflichtet, sich an irgendwelche Lizenzbedingungen halten, wenn er irgendwas mit seinem eigenen Werk (Programm, Buch, Lied, Foto …) macht.
Die Lizenzbedingungen gelten immer nur für andere, die sein Werk nutzen wollen.
Und was wird ihn das interessieren, wenn niemand mehr Code von ihm haben möchte? Er hatte doch eh nichts davon, also wird ihm das egal sein.
Ob er verurteilt wird, wir dsich zeigen. Ich glaube es nicht.
Hast du grundsätzlich Recht.
Insgesamt zeigt das aber einmal mehr, das bei Open Source auch nicht alles Gold ist was glänzt und man von heute auf morgen auf dem trockenen sitzen kann.
Versuch doch mal Office 2010 neu zu installieren – haste ja gekauft.
Der Autor darf mit seinem Code machen was er will – ist seiner.
Ich darf den nutzen – nett vom Autor.
Warum dann der Autor bitte immer nur perfekten Code pushen darf leitet sich für mich aus dem oben nicht ab.
Unabhängig davon, ob das jetzt böser Code war oder Aktivismus:
Wenn ich **direkt** auf den Code verweise ohne Zwischeninstanz (Distribution z.B.) dann ist es meine Schuld, wenn mein darauf aufbauender Code nicht klappt. Wenn ich Version 1.4.0 nutzen will – dann kann ich die Version nutzen (und vielleicht auch selber zu mir ziehen und vertreiben – darf ich ja. Dann bin ich auch sicher, dass das OK ist).
Wenn ich aber faul (weil ich nicht jedes Mal die Abhängigkeit für eine neue Version in meinem Code anpassen will) UND gierig (speichere es nicht lokal bei mir sondern ziehe es von der Quelle direkt) bin dann ist's halt meine Doofheit.
Auf archive.org ist sein Post, wo er versucht hat einer Firma seinen Code zu verkaufen – und die haben ihn auch nochmal absichtlich ausgenutzt: https://web.archive.org/web/20210628030444/https://marak.com/blog/2021-04-25-monetizing-open-source-is-problematic
Fazit: wenn ich auf was aufbaue, von dem ich sicher sein will, dass es klappt: wähle die konkrete Version UND halt die selber vor. Feddich
Gutes Beispiel. Office 2010 kann ich noch immer installieren. Völlig ohne Probleme.
Und aktivieren?
Gerade gestern habe ich ein Office 2010 installiert und aktiviert.
Was ich mit meinem Code mache ist doch mein Ding, ich kann dir den auch zu Verfügung stellen und du nutzt den wenn ich das freigebe vollkommen legal! (ob frei oder bezahlt ist irrelevant)
Aber es ist deine Pflicht zu prüfen ob der Code nach Änderungen noch für dich brauchbar ist. Ich kann mit meinem Code machen was ich möchte, wenn deine Software dann nicht mehr läuft ist das dein Problem: du bist in der Pflicht zu prüfen oder eben selbst zu coden! Ich bin nicht verpflichtet meinen Code wegen dir anzupassen das es dir passt!
Natürlich nicht nett sowas absichtlich zu machen, aber he mein Code meine Regeln … du musst den ja nicht nutzen.
Es wird wohl juristisch zu prüfen sein, ob Du mit Deinem Code machen kannst, was Du willst!
Immerhin ist er an die MIT gekoppelt und da wird er schon geregelt sein,
was Du dann noch mit "Deinem" Code so darfst.
Im Übrigen ist dieser Code mit der Offenlegung und der MIT öffentlich
und somit eben nicht mehr nur "DEIN" Code.
Dann nenne doch mal den entsprechenden Passus, der das so regelt.
Der Code ist immer noch mein geistiges Eigentum, du darfst den nur nutzen und frei verwenden ändern und so weiter …
Und du bist in der Pflicht zu prüfen ob der Code noch für deine Anwendung passt wenn ich meinen Code ändere nicht ich muss prüfen ob es passt!
Du verwendest "fremden Code" du hast die Verantwortung!
Ich kann eine MIT auch jederzeit wiederrufen damit wird die Verwenung durch dir ungültig. Nicht für alten Code unter MIT aber für jede neue Version!
Der Code ist immer noch mein geistiges Eigentum, du darfst den nur nutzen und frei verwenden ändern und so weiter …
Und du bist in der Pflicht zu prüfen ob der Code noch für deine Anwendung passt wenn ich meinen Code ändere nicht ich muss prüfen ob es passt!
Du verwendest "fremden Code" du hast die Verantwortung!
Ich kann eine MIT auch jederzeit wiederrufen damit wird die Verwendung durch dich ungültig. Nicht für alten Code unter MIT aber für jede neue Version!
Nur weil ich etwas unter eine Öffentliche Lizenz frei zur Verfügung stelle gebe ich noch lange nicht meine Rechte auf, du kannst damit ja forken und dann ist das wieder deine
Verantwortung … aber ich kann meinen Code jederzeit ändern wie ich es möchte oder brauche …
dadurch forderst Du aber effektiv, dass für jedes Paket ein Versions-Pinning genutzt wird – was wiederum dafür sorgt, dass Bugfixes wie früher Jahre brauchen, bis sie sich verbreiten.
Auch nicht ideal.
Jeder verantwortungsvolle Entwickler wird Versionspinning anwenden. Nur naive Einfaltspinsel winken externen Code ungeprüft in eigenen Projekten durch! – Sicherheitsprobleme, Funktionsausfälle, unter anderem wegen Kompatibilitätsproblemen, und Maleware, Virus und Trojaner-Gefahr ist sonst Tür und Tor geöffnet.
Alleine Ihre Beschwerde zeigt mir, wie wenig Sie die Lizenzen von Open Source kennen.
Erst genau nachdenken, dann beschweren! (FL)OSS-Quellen können korrumpiert werden, nicht nur seitens eines unzufriedenen Entwicklers/Maintainers!
Das ist absolutes Basiswissen, was aber immer wieder gerne aus Bequemlichkeit vorsätzlich ignoriert wird.
Ungeachtet einer Bewertung, ob die Aktion des Autors besonders clever war oder nicht, finde ich es bedenklich, dass Github als Reaktion darauf dem Autor einfach den Zugang zu seinem Repository verwehrt.
Gegen welchen Punkt der "Terms of Service" von Github genau hat er denn verstossen?
Das ist sein Code, was er damit macht, ist seine Entscheidung, selbst wenn er alles komplett löschen würde, verstösst das gegen keinen Punkt dort, oder hat er mit dem Upload irgendwelche langfristigen Verwertungsrechte an Github abgetreten?
Wenn andere seinen Code nutzen bzw. offenbar wie hier geschehen ungeprüft übernehmen, dann ist das alleine ihre Sache und zeigt ein viel tiefergehendes Problem auf, nämlich dass mit etwas "mehr Geschick" trotz bereits ähnlicher Vorfälle offenbar auch weiterhin einfach Backdoors u.ä. in kommerzielle Systeme verteilt werden könnten.
Den Autor dafür anzugreifen, dass man selbst nicht aufpasst, was man nutzt bzw. unhinterfragt übernimmt, ist klares Bellen an den falschen Baum. Das Komplettversagen liegt bei der Nutzerschaft.
Github gehört doch neu Microsoft? Dann macht die Sperre schon Sinn.
Github gehört doch neu Microsoft? Dann macht die Sperre schon Sinn.
er hätte den Code löschen dürfen. Er hätte auch die Lizenz ändern können.
Was er aber hier gemacht hat, nämlich *bewusst* Fehler einzubauen geht Richtung Computersabotage.
Dazuhin hat er nicht einfach ein "Pay me" ausgedruckt und beendet – er hat eine Endlosschleife verwendet und dann auch noch im Bugtracker so getan, als sei das ein Bug und er arbeite dran:
"It's come to our attention that there is a zalgo bug in the v1.4.44-liberty-2 release of colors.
Please know we are working right now to fix the situation and will have a resolution shortly."
Finde ich schon irgendwo verständlich, da ist viel Frust und deshalb die Reaktion.
Open Source kann man nutzen, man kann Bedingungen wie eine Lizenzierung stellen, was er scheinbar nicht gemacht hat. Dennoch ist ihm der Hut hochgegangen weil von den Großen Konzernen so gar kein Dank kam.
Umgekehrt hat niemand das Recht bestimmte Eigenschaften von einem Open Source Projekt zu fordern, in der Regel wird solche Software zur Verfügung gestellt wie sie ist. Wenn einigen ihre Projekte wegen einer "kaputten" Abhängigkeit um die Ohren geflogen sind, dann doch nur deshalb weil sie diese Open-Source-Projekte genutzt haben ohne nachzudenken und ihre eigene Sorgfaltspflicht vernachlässigt haben.
Im Grunde können alle froh sein, dass da durch Dritte verursacht keine Malware drin war. Sie hätten es vielleicht erst gemerkt wenn es zu spät gewesen wär.
Hat er eben doch!! Er hat seinen Code unter MIT gestellt.
Und jetzt regt er sich auf, dass er mit seiner Arbeit kein Geld verdient?
Hat der "Gute" die Lizenz nicht verstanden oder gar gelesen?
Sorry mein Fehler. Es sollte eigentlich heißen "Bedingungen für eine Lizezierung", Er hätte natürlich eine Lizenz wählen können die ihm sinvoll erscheint.
Die Welt dreht sich weiter, und er entwickelt nicht weiter – die Soft wird inkompatibel, Abandonware, nichts funktioniert mehr. Trotz MIT-Lizenz!1!!
Also verklagen wir ihn doch! Er wird schon sehen, was er davon hat, nichts mehr zu tun! Wo kämen wir dahin, wenn jemand sagen könnte: Fork doch! und keiner macht's….
Als Programmierer gefällt mir der Open-Source-Gedanke sehr. Doch soviel ich auch drüber nachdenke – für mich funktioniert er nicht. Ich muss Miete bezahlen, Essen kaufen usw. Ich kann meine Arbeit einfach nicht verschenken.
Der spezielle Fall ist jedoch irgendwie anders. Er hat seine Arbeit verschenkt. Und kann oder will damit jetzt nicht leben?
Du kannst ja eine (viel) ältere Version deiner Arbeit unter Open-Source veröffentlichen. Dann verdienst du weiterhin dein Geld mit den aktuellen Codes und kannst trotzdem sehen, was andere mit deinen Code noch alles machen. Je nach dem, wie geschickt du die Lizenz wählst, kannst du nützliche Änderungen (auf die evtl. sonst nicht gekommen wärst) in deinen neue Codes integrieren und das wiederum als Neuerung verkaufen.
Udo Pütz hat ja einen alten Artikel des Autors weiter oben verlinkt, wo man sehr schön nachlesen kann, wie da Frust aufgebaut wurde.
Ich sehe auch weniger den Entwickler, der jetzt verbrannt ist. Sondern das Modell der Firmen, da FOSS direkt per npm einzubinden und dann mit staunenden Augen zu schauen, wenn was passiert. Es hat jetzt so oft mit Schwachstellen und Hacks geknallt, aber die Branche hat den Schuss immer noch nicht gehört …
Ich sehe Open Source auch positiv – nutze ich hier im Blog mit WordPress. Bei den Plugins halte ich es so, dass aktive Entwickler und andere Projekte ihre Donations bekommen. Und bei einem Plugin habe ich bewusst die kostenpflichtige Fassung im Einsatz, um den Entwickler zu unterstützen.
Was er gemacht hat, das machen auch große Firmen regelmäßig. In einer neuen Version funktioniert plötzlich vieles nicht mehr was vorher problemlos lief.
Nur mit dem Problem, dass du dann weder Sourcecode hast, noch irgendwie sonst zurück kannst (siehe Apple).
Wer das ohne ausführlichen Test nimmt ist selbst schuld.
Wo ist der Lizenzverstoß?
Er hat sein Programmablauf weiterentwickelt.
Der neue Programmablauf macht halt andere Dinge als der alte. Wo ist das Problem mit der MIT-Lizenz?
Da steht nirgends, das der Entwickler bestimmte Funktionen garantiert oder dafür haftet, wenn er seinen Programmablauf (komplett) ändert. Er muß die bereitgestellten Features nicht mal (vollständig) dokumentieren!
Die Plattform GIT bietet Versionierung. Wer sich an fremdem Quellcode bedient, sollte dieses Feature auch zielführend nutzen! Alles andere ist Bullshit, Dummheit und zeugt von vollkommener Verantwortungslosigkeit!
Wie auch schon einige hier korrekt geschrieben haben: Der Nutzer der Bibliothek ist verpflichtet, den Programmablauf der Bibliotheken nach jedem Update zu prüfen, ob dieser noch immer für sein Projekt geeignet ist! Diesen Schritt haben sich scheinbar ein Großteil der Nutzer gespart, und ungeprüft jedes Update ins eigene Projekt übernommen. Klassischer Fall von Open Source Lizenz (hier MIT) und Open Source Prinzip nicht verstanden, Dumm, naiv und "Geiz ist geil"-Mentalität.
Aber auch ein erneuter Weckruf für alle, die immer noch nicht externe Quellen prüfen, bevor sie diese in eigenen Projekten referenzieren.
Juristisch ist der Entwickler nicht angreifbar, auch wenn das hier in den Kommentaren gerne herbeifabuliert wird.
Wenn kommerzielle Projekte betroffen sind, sind kommerziellen Organisationen für die Einbindung ungeprüften externen Codes in eigene Projekte aber durchaus haftbar. Bin gespannt ob da eine eventuelle Versicherung überhaupt greift, da die Sorgfaltspflicht nicht ansatzweise wahrgenommen wurde.
Wer nicht sauber arbeitet, muß sich nicht wundern, wenn sein Projekt in Probleme läuft, weil er geschlampt hat.