SAN FRANCISCO, CA - In the wake of a devastating supply chain attack in the npm registry that left millions of enterprise applications compromised and billions of user records exposed, developers across the JavaScript ecosystem expressed deep sorrow today, lamenting that such a crisis was completely unavoidable.

“It’s a shame, but what can you do? This is just the price of building modern web apps,” said Senior Frontend Engineer Mark Vance, echoing the sentiments of a community that completely relies on a 40-level-deep nested tree of unvetted packages maintained by pseudonymous strangers to capitalize a single string. “There’s absolutely no way to foresee or prevent someone from taking over a long-abandoned utility package and injecting a crypto-miner into every production build in the world. It’s just an act of nature.”

  • Swedneck@discuss.tchncs.de
    link
    fedilink
    arrow-up
    9
    ·
    11 hours ago

    Amazing that moderate-effort generated images look this good now, and yet i immediately twigged that it’s not a real photo.
    Lo and behold i look closer and indeed the text is garbled nonsense.

    Are they intentionally priming the models to have this weird aura of surreality? Or is it just something inherent to AI-generated images that’s somehow really difficult to avoid?

      • Swedneck@discuss.tchncs.de
        link
        fedilink
        arrow-up
        4
        ·
        10 hours ago

        While this is true, there’s still a very consciously visible “style” to these images. It’s too obvious for me to call it subconscious.
        Like the weird focus, the text on the whiteboard looking like a digital font… The individual things that are weird are quite easy to point out.

      • whoisearth@lemmy.ca
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        2 hours ago

        Two phrases come to mind

        1. Play shitty games. Win shitty prizes
        2. Vote for a clown. Elect a circus.

        Personal experience. JavaScript is garbage on its own. Npm is a Russian nesting doll of untenable garbage built on it.

  • tabular@lemmy.world
    link
    fedilink
    English
    arrow-up
    17
    ·
    22 hours ago

    I’m sure there are advatages to making web apps over regular software for OS’s and that supply attacks can happen anywhere… but the idea this is unavoidable is insanity. Stop making reckless “modern” web apps.

    Speaking of “modern web apps” does OpenSUSE still use Firefox as an installer? When I tried the new major version on release I watched a browser unexpectedly open and slowly load a page. Coming from a snappy dedicated installer of prior versions, this made me question if I had downloaded malware.

    • BrianTheeBiscuiteer@lemmy.world
      link
      fedilink
      arrow-up
      28
      ·
      18 hours ago

      It “regularly happens” in NPM because it has one of the biggest attack surfaces. You think hackers are spending a meaningful amount of time taking over abandoned Lua projects?

      • 5ymm3trY@discuss.tchncs.de
        link
        fedilink
        arrow-up
        4
        ·
        10 hours ago

        Things like the AUR in Arch Linux are also susceptible to this. About a year ago there were malicious versions of popular browsers e.g. firefox-patch-bin or librewolf-fix-bin in the AUR. As others have said, NPM has a huge attack surface because it is practically used by everyone which is probably why it is targeted a lot more.

      • mabeledo@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        11 hours ago

        Because distro packages rely on a small group of trusted maintainers, while anyone can publish anything to the NPM registry.

        Also, distro packages are usually full fledged applications or libraries, which require a certain number of developers upstream to maintain them. There are thousands of NPM packages out there that are essentially walking corpses waiting to be infected.

      • Piatro@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        ·
        14 hours ago

        One of these days I should really look at the specific differences that means Linux packages rarely experience this while npm it happens seemingly once a month.

        • iglou@programming.dev
          link
          fedilink
          arrow-up
          5
          ·
          13 hours ago

          Typically people only have trustworthy repositories configured. The amount of people with access to deploy on those is low. Less keys, less chance of someone stealing one.

          Plus, let’s be honest, people deploying linux packages are probably much more security-conscious than people deploying a random but useful javascript lib on npm.

  • tal@lemmy.today
    link
    fedilink
    English
    arrow-up
    17
    ·
    edit-2
    24 hours ago

    It doesn’t seem like a crazy idea to me to have some “second tier” of packages that undergo a higher level of scrutiny and have to pass that before they are released in that tier.

    Maybe an arbitrary set of security endorsements would be more flexible.

    That permits retaining a low bar for just making the stuff initially-accessible in packaged format, but also helps developers in raising the floor.

    Like, okay. Say I have something like:

    $ cat .config/npmrc
    required_security_endorsements=["npm_auto_audit", "maintainer_id_validated", "european_cybersecurity_competence_center_tier_1", "nsa_tier_1"]
    $
    

    An attempt to install a release of a package without those endorsements fails.

    That’s going to always create pressure to get something a security endorsement so that it can be used by people who only permit packages with some given security endorsement, but it lets parties start running security endorsement projects to improve the situation without excluding any existing projects from pushing stuff to npm.

    EDIT: Also, I’ve not done much node.js development, but assuming that the dependencies in a package manifest default to the newest version unless specific frozen versions are mandated, a la PyPI, it might reasonably be able to fall back to versions with the required security level automatically, if they’re available. If the dependency format permits specifying optional dependencies, a particular dependency could be automatically excluded to conform to the security endorsement requirements list.

    • MonkderVierte@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      11 hours ago

      to have some “second tier” of packages that undergo a higher level of scrutiny and have to pass that before they are released in that tier.

      The reverse: to have a trusted category, where they know the dev.

    • shirasho@feddit.online
      link
      fedilink
      English
      arrow-up
      23
      ·
      22 hours ago

      A much simpler solution is to add all of the basic stuff into the base library so that people don’t need to include 50 packages to do stupidly simple stuff, but Javascript has shown very little desire to harden itself or grow. They have relied on community contribution to fill their missing design holes and now it is biting them in the butt.

      • msage@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        13 hours ago

        Many things are working in vanilla, just packages are created for fun? Like isEven, isThrteen and so on.

    • locuester@lemmy.zip
      link
      fedilink
      English
      arrow-up
      7
      ·
      20 hours ago

      Devs can add these to .npmrc. And in top tier professional workplaces we do things like this. Sure devs can override, but it’s explicit at that point.

      ignore-scripts=true
      min-release-age=14
      

      In enterprises all packages are copied, scanned, and hosted internally with requests for packages from public locations blocked.

    • onlinepersona@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      20 hours ago

      Great ideas. Who’s going to pay for it? Are opensource devs supposed to wrote the code, maintain it, and audit other people’s code too?

  • ijhoo@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    13 hours ago

    what would be a possible alternative?

    going directly to repos of e.g. tanstack?

    • sus@programming.dev
      link
      fedilink
      arrow-up
      8
      ·
      12 hours ago

      The simplest fix is a delay between an update being pushed and the update being deployed everywhere. Several orgs are scanning all popular dependencies for supply chain attacks and they usually catch them quickly, just not quickly enough when there is no delay.

    • NostraDavid@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      12 hours ago

      Vet certain versions of packages, and use those whenever you can, also for subdependencies. Effectively create ‘stable’ versions of packages that are guaranteed safe to use.

      Yes, it’ll be a ton of extra work, but that’s the price for security.

      • iglou@programming.dev
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        edit-2
        12 hours ago

        And this is one of the reasons C is not more popular. C is not a model for modern programming.

        • mabeledo@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          11 hours ago

          I don’t know why it wouldn’t. This is the model Go uses, their package registry is just a glorified index of code repositories.

          C is not that popular nowadays because most devs don’t want to deal with the tradeoffs, most importantly memory handling and management.

  • Korkki@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    23 hours ago

    Didn’t pypi have the worm too recently?

    Also I have no idea why npm is worse offender than most? Is it that the install scripts can you execute any code they want?

    • iglou@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      13 hours ago

      Because there is a much larger number of small libraries that end up in every project somewhere down the tree. So: higher count of opportunities.

      Because JS is much more popular than any other language and is used in virtually every web project. So: higher impact when successfully executing a supply chain attack. (this is the same reason why Windows has more viruses than linux or osx: not because linux and osx are intrinsically more secure - even if they are, that’s never going to be the main factor - but because there are a lot more tech illiterate users with Windows than the others)

      NPM isn’t particularly less secure, it’s just more attractive to exploit.

    • grue@lemmy.world
      link
      fedilink
      arrow-up
      14
      ·
      19 hours ago

      Also I have no idea why npm is worse offender than most?

      I think it’s because JavaScript devs have a more promiscuous culture of code reuse than most. In what other language community would something like left-pad justify being its own package?

  • thingsiplay@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    22 hours ago

    For the longest time I was avoiding the npm. But for certain stuff I needed it to set up my Neovim environment, that depends on npm. And reading headlings and articles like these makes me feel very uncomfortable. Not sure if I should re-evaluate my setup.

  • terroristtaco@lemmychan.org
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    23 hours ago

    Fuck NPM and all the stupid morons that perpetuate it.

    I knew I was making the right choice whenever I avoided that dumb shit like the plague.