Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Newsnpm als Malware-Schleuder: GitHub kontrolliert Pakete vorab
GitHub führt eine zusätzliche Sicherheitskontrolle für die Paketverwaltung npm ein. Neu veröffentlichte Softwarepakete werden automatisch auf Schadcode geprüft und erst danach zur Installation freigegeben. Verdächtige Pakete können zurückgehalten oder vollständig blockiert werden.
Wird das genauso gut geprüft wie von Canonical der SNAP-Store?
Ansonsten weg damit, entweder es kommt aus BaseOS/AppStream bzw. Main/Contrib/Non-Free oder es existiert schlicht nicht.
npm, pip, cpan, cargo, etc. alles weg damit.
GitHub sollte man nicht blind vertrauen, auch wenn ich bei den zahlreichen Tools in all den Jahren nur eine einzige Malware hatte (keine false positiv wo nur Windows Defender meckert).
Das Argument, dass der Quellcode dort ja immer einsehbar ist und somit einer Kontrolle unterliegt ist ein Scheinargument. Bei wenig bekannten Tools z.B. schauen bestimmt nicht zig Leute über den Quellcode um ihn zu prüfen.
Bei Paketen müsste dann schon jemand auf Code-Ebene alles prüfen, unter Berücksichtigung des Einsatzszweckes etc. Für den einen wäre eine Utilily-lib mit Hilfsfunktionen zum rekursiven Löschen von Verzeichnisbäumen bereits ein potentielles Sicherheitsrisiko, für den anderen gewollte Funktion. Das lässt sich auf beliebig viele Szenarien ausdehnen.
Leider keine triviale Aufgabe, aber jede Hürde, die es zu nehmen gilt, kann das insgesamt leider nur versuchen zu verbessern. Am Ende müssten Entwickler sich mehr dafür interessieren, was sie so einsetzen und auch mal schauen, was sie sich für Dependencies ins Porjekt holen. Aber ich glaube dieses Mindset geht mit dem ganzen Vibe-Coding gerade verloren :-) ...
Das ist kein Scheinargument, sondern ein "Strohmann", da die von Dir formulierte Konjunktion unlauter ist. Ich unterstelle Dir keine Absicht, allerdings aber eine missverständliche Auffassung.
Öffentlicher einsehbarer Code ist für jeden einsehbar und kann genau deswegen von einer Öffentlichkeit gereviewed werden. Das heißt aber natürlich nicht, dass ein solcher Review ein zwingender Prozessschritt (Kontrollpunkt) im Releaseprozess ist. Er ist das natürlich bisher nicht.
Der im Artikel beschriebene Ansatz geht aber automatisiert in diese Richtung. Ja, es wird sowohl false positives und als auch weiterhin slip throughs geben. Aber egal, was ich oder andere von node.js/npm halte: Das ist ein wichtiger Schritt, denn dieses "Ökosystem" ist faktisch relevant "da draußen".
Weil das mit Scans auf vermeintlich bösen Code in den letzten 35 Jahren erfolgreich war?
Die Gemeinschaft um JavaScript interessiert sich historisch wenig für Sicherheit. Es wurde definiert, dass der Webbrowser sicher ist und in dessen Sandbox nicht passieren kann. Tja. Doch? Und dass das nicht auf dem System selbst ausgeführt wird. Auftritt Node.js und Electron als Sparmassnahmen. Tja. Doch? Und irgendwie haben sich die Leute eingebildet, dass Abhängigkeiten für die Entwickler nicht gefährlich ist...leider doch.
Ich arbeite täglich mit JavaScript. Es ist ein Fluch.
Jede Website mit PHP und CGI ist angenehmer, schneller und verlässlicher. Hut ab an Amazon, die Website funktioniert einwandfrei ohne JavaScript. Stackoverflow bisher auch, aber bei dem neuen Eigner erwarte ich wenig Gutes.
@flaphoschi
Was ist jetzt Dein Begehr, den Du mit Deinem Rant verfolgst? Soll Github das lassen?
JS ist seit Jahrzehnten ein wesentlicher Teil von Software. Es ist auch egal, wie man heute retrospektiv beurteilt, ob Brendan Eich damals ein Verbrechen begangen oder eine geniale Idee hatte. Das "Zeug" ist in der Welt und wird auch so schnell nicht mehr verschwinden.
Ich sage immer: Wenn, dann Typescript mit strict und hardcore Linter-Vorgaben - und, wenn möglich, nur dev-dependencies.
Bei Paketen müsste dann schon jemand auf Code-Ebene alles prüfen, unter Berücksichtigung des Einsatzszweckes etc. Für den einen wäre eine Utilily-lib mit Hilfsfunktionen zum rekursiven Löschen von Verzeichnisbäumen bereits ein potentielles Sicherheitsrisiko, für den anderen gewollte Funktion. Das lässt sich auf beliebig viele Szenarien ausdehnen.
[...]
Die Erklärung zu npm im Artikel ist ziemlich unpräzise für eine Seite mit technikaffiner Leserschaft. Der Großteil neuer Pakete wird seit langem in TypeScript geschrieben und die Zielplattform ist schon lange nicht mehr primär Node.js.
@flaphoschi
Wut? Das Problem ist nicht JS/TS, sondern npm als Modell: ein gekaperter Maintainer-Account reicht für zehntausende kompromittierte Projekte. Governance-Problem, kein Sprachproblem. Das Risiko sitzt in der Lieferkette.
Und wo genau ist PHP da besser? Antiquiert und sperrig, aber nicht sicherer.
@PhiE man hätte ruhig nochmal erwähnen können, dass npm 2020 von GitHub gekauft wurde. War selbst mir als Entwickler, der jedoch nicht im Javascript Kontext unterwegs ist, gar nicht (mehr) bewusst.
PS: Hab gerade mal die CB News durchsucht. Wurde hier anscheinend gar nicht drüber berichtet. Nur über die Übernahme von GitHub seitens Microsoft (was denke ich jedem bekannt ist).
