Einige Entwickler verunstalten Open-Source-Software

Das Erstaunlichste an Open Source ist nicht, dass es großartige Software hervorbringt. Es ist so, dass so viele Entwickler ihr Ego beiseite legen, um mit der Hilfe anderer großartige Programme zu entwickeln. Mittlerweile stellen jedoch eine Handvoll Programmierer ihre eigenen Anliegen über das Wohl der vielen und potenziell schädlichen Open-Source-Software für alle.

Zum Beispiel der Betreuer des JavaScript-Paketmanagers RIAEvangelist, Brandon Nozaki Miller, hat ein Open-Code-NPM-Quellcodepaket namens Peacenotwar geschrieben und veröffentlicht. Es hat wenig bewirkt, außer eine Friedensbotschaft auf den Desktops zu drucken. So weit, so harmlos. 

Anschließend fügte Miller Schadcode in das Paket ein, um die Dateisysteme der Benutzer zu überschreiben, wenn deren Computer über eine russische oder weißrussische IP-Adresse verfügten. Anschließend fügte er es als Abhängigkeit zu seinem beliebten hinzu Knoten-IPC Programm und sofortiges Chaos! Zahlreiche Server und PCs fielen aus, als sie auf den neuesten Code aktualisiert wurden, und anschließend wurden die Laufwerke ihrer Systeme gelöscht. 

Millers Verteidigung: „Dies alles ist öffentlich, dokumentiert, lizenziert und Open Source„hält nicht stand. 

Liran Tal, der Snyk Der Forscher, der das Problem aufdeckte, sagte: „Auch wenn die vorsätzliche und gefährliche Handlung von einigen als legitimer Protestakt angesehen wird, Wie wirkt sich das auf den zukünftigen Ruf des Betreuers aus? und Beteiligung an der Entwickler-Community? Wäre diesem Betreuer jemals wieder zuzutrauen, dass er künftige Handlungen in solchen oder noch aggressiveren Aktionen für Projekte, an denen er beteiligt ist, nicht weiterverfolgt?“ 

Miller ist kein zufälliger Spinner. Er hat viel guten Code produziert, wie zum Beispiel Node-IPC und Knoten-HTTP-Server. Aber können Sie darauf vertrauen, dass sein Code nicht bösartig ist? Während er es beschreibt als „keine Malware, [sondern] Protestware, die vollständig dokumentiert ist“, widersprechen andere giftig. 

Wie ein GitHub-Programmierer schrieb: „Was dabei passieren wird, ist, dass Sicherheitsteams in westlichen Unternehmen, die absolut nichts mit Russland oder der Politik zu tun haben, anfangen werden, es zu sehen.“ freie und Open-Source-Software als Möglichkeit für Angriffe auf die Lieferkette (was das völlig ist) und einfach anfangen, freie und Open-Source-Software – alles freie und Open-Source-Software – in ihren Unternehmen zu verbieten.“ 

Ein anderer GitHub-Entwickler mit dem Handle nm17 schrieb: „The Vertrauensfaktor von Open Source, das auf dem guten Willen der Entwickler beruhte, ist nun praktisch verschwunden, und immer mehr Menschen erkennen, dass ihre Bibliothek/Anwendung eines Tages möglicherweise ausgenutzt werden kann, um alles zu tun/sagen, was irgendein zufälliger Entwickler im Internet gedacht hat. war das Richtige für sie.‘“

Beide bringen berechtigte Argumente vor. Wenn Sie Quellcode nur dann verwenden können, wenn Sie mit der politischen Haltung seines Erstellers einverstanden sind, wie können Sie ihn dann mit Zuversicht verwenden? 

Millers Herz ist vielleicht am rechten Fleck – Slava Ukraini! – Aber ist Open-Source-Software, die mit einer bösartigen Nutzlast infiziert ist, der richtige Weg, um Russlands Invasion in der Ukraine zu schützen? Nein, ist es nicht. 

Die Open-Source-Methode funktioniert nur, weil wir einander vertrauen. Wenn dieses Vertrauen zerstört wird, egal aus welchem ​​Grund, dann wird das Grundgerüst von Open Source zerstört. Wie Greg Kroah-Hartman, der Betreuer des Linux-Kernels für den Stable-Zweig, sagte, als Studenten der University of Minnesota im Jahr 2021 absichtlich versuchten, fehlerhaften Code in den Linux-Kernel für ein Experiment einzufügen, sagte er: „Was sie tun, ist absichtlich bösartiges Verhalten und.“ ist inakzeptabel und völlig unethisch.“

Es wird seit langem argumentiert, dass Open Source auch ethische Bestimmungen beinhalten sollte. Zum Beispiel 2009 Ausnahme General Public License (eGPL), eine Überarbeitung des GPLv2, versuchte „Ausnahmen“ wie militärische Nutzer und Zulieferer die Nutzung seines Codes zu verbieten. Es ging schief. Andere Lizenzen wie die JSON-Lizenz Die süßlich naive Klausel „Die Software soll zum Guten und nicht zum Bösen verwendet werden“ gibt es immer noch, aber niemand setzt sie durch.  

Vor Kurzem führte die Aktivistin und Softwareentwicklerin Coraline Ada Ehmke eine Open-Source-Lizenz ein, die von ihren Nutzern moralisches Verhalten verlangt. Genauer gesagt, sie Hippokratische Lizenz Um die hinzugefügte MIT Open-Source-Lizenz eine Klausel, die besagt: 

„Die Software darf nicht von Einzelpersonen, Unternehmen, Regierungen oder anderen Gruppen für Systeme oder Aktivitäten verwendet werden, die aktiv und wissentlich das körperliche, geistige, wirtschaftliche oder allgemeine Wohlergehen benachteiligter Personen oder Gruppen gefährden, schädigen oder auf andere Weise bedrohen.“ Verletzung der Allgemeinen Erklärung der Menschenrechte der Vereinten Nationen.“

Klingt gut, ist aber nicht Open Source. Sie sehen, Open Source ist an und für sich eine ethische Position. Seine Ethik ist in der enthalten Free Software Foundation (FSF)'s Vier wesentliche Freiheiten. Dies ist die Grundlage aller Open-Source-Lizenzen und ihrer Kernphilosophie. Wie der Open-Source-Rechtsexperte und Columbia-Rechtsprofessor Eben Moglen damals sagte, dass ethische Lizenzen keine freie Software oder Open-Source-Lizenzen sein können: 

"Freiheit Null, das Recht, das Programm für jeden Zweck auszuführen, steht an erster Stelle der vier Freiheiten, denn wenn Benutzer dieses Recht in Bezug auf die von ihnen ausgeführten Computerprogramme nicht haben, haben sie letztendlich überhaupt keine Rechte an diesen Programmen. Bemühungen, nur gute Nutzungen zu genehmigen oder in den Augen des Lizenzgebers schlechte zu verbieten, verstoßen gegen das Gebot, die Freiheit Null zu schützen.“ 

Mit anderen Worten: Wenn Sie Ihren Code aus irgendeinem Grund nicht teilen können, ist Ihr Code nicht wirklich Open Source. 

Ein weiteres pragmatischeres Argument dafür, einer Gruppe die Nutzung von Open-Source-Software zu verbieten, ist, dass das Blockieren von Dingen wie einer IP-Adresse ein sehr weit gefasster Begriff ist. Als Florian Roth, Sicherheitsunternehmen Nextron-Systeme' Forschungsleiter, der überlegte: „Deaktivieren meiner kostenlosen Tools auf Systemen mit bestimmten Sprach- und Zeitzoneneinstellungen“, entschied sich schließlich dagegen. Warum? Denn dadurch „Wir würden auch die Tools auf Systemen von Kritikern und Freidenkern deaktivieren die das Vorgehen ihrer Regierungen verurteilen.“ 

Leider sind es nicht nur Menschen, die versuchen, Open Source für einen aus ihrer Sicht höheren ethischen Zweck zu nutzen, die der Open-Source-Software Probleme bereiten. 

Anfang des Jahres sabotierte der JavaScript-Entwickler Marak Squires absichtlich seine obskuren, aber lebenswichtigen Open-Source-Javascript-Bibliotheken „colors.js“ und „faker.js“. Das Ergebnis? Zehntausende JavaScript-Programme sind in die Luft geflogen.

Warum? Es ist immer noch nicht ganz klar, aber in einem inzwischen gelöschten GitHub-Beitrag schrieb Squires: „Mit Respekt, Ich werde keine Fortune-500-Unternehmen mehr unterstützen (und andere kleinere Unternehmen) mit meiner freien Arbeit. Es gibt nicht viel mehr zu sagen. Nutzen Sie dies zum Anlass, mir einen sechsstelligen Jahresvertrag zuzusenden oder das Projekt abzuspalten und jemand anderen damit beauftragen zu lassen.“ Wie Sie sich vorstellen können, funktionierte dieser Versuch, seinen Gehaltsscheck zu erpressen, für ihn nicht so gut. 

Und dann gibt es Leute, die aus Spaß und Profit absichtlich Malware in ihren Open-Source-Code einbauen. Zum Beispiel das DevOps-Sicherheitsunternehmen JFrog entdeckte 17 neue JavaScript-Schadpakete im NPM-Repository, die absichtlich die Discord-Tokens eines Benutzers angreifen und stehlen. Diese können dann auf dem verwendet werden Discord-Kommunikations- und digitale Vertriebsplattform.

Neben der Entwicklung neuer bösartiger Open-Source-Programme, die harmlos und hilfreich aussehen, nehmen andere Angreifer alte, verlassene Software und schreiben sie um, um Hintertüren zum Diebstahl von Kryptomünzen einzubinden. Ein solches Programm war Event-Stream. Darin wurde bösartiger Code eingeschleust, um Bitcoin-Wallets zu stehlen und deren Guthaben an einen Server in Kuala Lumpur zu übertragen. Im Laufe der Jahre gab es mehrere ähnliche Episoden.

Mit jedem solchen Schritt schwindet das Vertrauen in Open-Source-Software. Da Open Source für die moderne Welt absolut lebenswichtig ist, ist das ein mieser Trend. 

Was können wir dagegen tun? Nun, zum einen sollten wir sehr sorgfältig überlegen, wann, wenn überhaupt, wir die Verwendung von Open-Source-Code blockieren sollten. 

In der Praxis müssen wir beginnen, die Verwendung von zu übernehmen Linux Foundation Softwarepaket-Datenaustausch (SPDX) und Software-Stückliste (SBOM). Zusammen sagen uns diese genau, welchen Code wir in unseren Programmen verwenden und woher er kommt. Dann werden wir viel besser in der Lage sein, fundierte Entscheidungen zu treffen.

Heutzutage verwenden Menschen nur allzu oft Open-Source-Code, ohne genau zu wissen, was sie ausführen, oder ohne ihn auf Probleme zu überprüfen. Sie gehen davon aus, dass damit alles in Ordnung ist. Das war noch nie eine kluge Annahme. Heute ist es geradezu dumm. 

Trotz all dieser jüngsten Änderungen ist Open Source immer noch besser und sicherer als die proprietären Black-Box-Softwarealternativen. Aber wir müssen den Code überprüfen und verifizieren, anstatt ihm blind zu vertrauen. Das ist die einzig kluge Entscheidung für die Zukunft.

Ähnliche Beiträge: