Most active commenters

    ←back to thread

    Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

    (socket.dev)
    1208 points jamesberthoty | 13 comments | 16 Sep 25 11:22 UTC | HN request time: 1.182s | source | bottom
    Show context
    codemonkey-zeta ◴[16 Sep 25 11:56 UTC] No.45261026[source]▶
    I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem.

    These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.

    replies(18): >>45261086 #>>45261121 #>>45261140 #>>45261165 #>>45261220 #>>45261265 #>>45261285 #>>45261457 #>>45261571 #>>45261702 #>>45261970 #>>45262601 #>>45262619 #>>45262851 #>>45267210 #>>45268405 #>>45269073 #>>45273081 #
    jeswin ◴[16 Sep 25 13:27 UTC] No.45261970[source]▶
    Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of.

    However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

    replies(6): >>45262184 #>>45262208 #>>45262220 #>>45262223 #>>45262238 #>>45264048 #
    1. WD-42 ◴[16 Sep 25 13:46 UTC] No.45262220[source]▶
    Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over.

    [1]https://www.npmjs.com/package/uuid

    replies(5): >>45262335 #>>45262791 #>>45263174 #>>45263227 #>>45264429 #
    2. skydhash ◴[16 Sep 25 13:55 UTC] No.45262335[source]▶
    You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture.

    > You can't expect people to re-write everything over and over.

    That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.

    replies(2): >>45263264 #>>45274064 #
    3. jmull ◴[16 Sep 25 14:32 UTC] No.45262791[source]▶
    FYI, there's crypto.randomUUID()

    That's built in to server side and browser.

    4. simiones ◴[16 Sep 25 14:56 UTC] No.45263174[source]▶
    That's not the problem. There is a cultural (and partly technical) aversion in JavaScript to large libraries - this is where the issue comes from. So, instead of having something like org.apache.commons in Java or Boost in C++ or Posix in C, larger libraries that curate a bunch of utilities missing from the standard library, you get an uncountable number of small standalone libraries.

    I would bet that you'll find a third party `leftpad` implementation in org.apache.commons or in Spring or in some other collection of utils in Java. The difference isn't the need for 3rd party software to fix gaps in the standard library - it's the preference for hundreds of small dependencies instead of one or two larger ones.

    replies(2): >>45264977 #>>45268119 #
    5. ◴[16 Sep 25 14:59 UTC] No.45263227[source]▶
    6. chamomeal ◴[16 Sep 25 15:01 UTC] No.45263264[source]▶
    When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”.

    I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture

    replies(1): >>45263944 #
    7. jlarocco ◴[16 Sep 25 15:53 UTC] No.45263944{3}[source]▶
    It's not really bad advice, it just has different implications in Javascript.

    In other languages, you'd have a few dependencies on larger libraries providing related functionality, where the Javascript culture is to use a bunch of tiny libraries to give the same functionality.

    replies(1): >>45264086 #
    8. lenerdenator ◴[16 Sep 25 16:03 UTC] No.45264086{4}[source]▶
    Sometimes I wonder how many of these tiny libraries are just the result of an attempt to have something ready for a conference talk and no one had the courage to say "Uh, Chris, that already exists, and the world doesn't need your different approach on it."
    9. lupusreal ◴[16 Sep 25 16:29 UTC] No.45264429[source]▶
    > You can't expect people to re-write everything over and over.

    Call me crazy but I think agentic coding tools may soon make it practical for people to not be bogged down by the tedium of implementing the same basic crap over and over again, without having to resort to third party dependencies.

    I have a little pavucontrol replacement I'm walking Claude Code through. It wanted to use pulsectl but, to see what it could do, I told it no. Write your own bindings to libpulse instead. A few minutes later it had that working. It can definitely write crap like leftpad.

    10. knert ◴[16 Sep 25 17:09 UTC] No.45264977[source]▶
    1000% agree. Javascript is weak in this regard if you compare it to major programming languages. It just adds unnecessary security risks not having a language with built in imports for common things like making API calls out or parsing JSON, for example.
    replies(1): >>45268156 #
    11. anon7000 ◴[16 Sep 25 21:12 UTC] No.45268119[source]▶
    Lodash is a good counterpoint, but it’s falling out of style since the JS runtimes support more basic things now.

    JS apps, despite the HN narrative, have a much stronger incentive to reduce bundle/“executable” size compared to most other software, because the expectation is for your web app to “download” nearly instantly for every new user. (Compare to nearly any other type of software, client or server, where that’s not an expectation.)

    JS comes with exactly zero tools out of the box to make that happen. You have to go out of your way to find a modern toolchain that will properly strip out dead code and create optimized scripts that are as small as possible.

    This means the “massive JS library which includes everything” also depends on having a strong toolchain for compiling code. And while may professional web projects have that, the basic script tag approach is still the default and easiest way to get started… and pulling in a massive std library through that is just a bad idea.

    This baseline — the web just simply having different requirements around runtime execution — is part of where the culture comes from.

    And because the web browser traditionally didn’t include enough of a standard library for making apps, there’s a strong culture of making libraries and frameworks to solve that. Compare to native apps, where there’s always an official sdk or similar for building apps, and libraries like boost are more about specific “lower level” language features (algorithms, concurrency, data structures, etc) and less about building different types of software like full-blown interactive applications and backend services.

    There are attempts to solve this (Deno is probably the best example), but buy-in at a professional level requires a huge commitment to migrate and change things, so there’s a lot of momentum working against projects like that.

    12. anon7000 ◴[16 Sep 25 21:14 UTC] No.45268156{3}[source]▶
    It does have functions for that, “fetch” and “JSON.parse,” available in most JS runtimes.
    13. user34283 ◴[17 Sep 25 10:34 UTC] No.45274064[source]▶
    It's a waste of time to strictly vet dependencies on my side when adding the standard test runner by Meta - jest - alone adds 300 packages to my dependency graph.

    So yes, the sprawling deps tree and culture is the problem. We would need to start reducing dependencies of the basic tools first. Otherwise it seems rather pointless to bother app developers with reducing dependencies.