• Meron35@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    2 days ago

    As someone completely unfamiliar with the JavaScript mess, are these security issues specific to npm the actual repository or npm the package manager?

    If it’s the latter, does using something else like yarn or bun instead help?

    • [object Object]@lemmy.ca
      link
      fedilink
      English
      arrow-up
      10
      ·
      1 day ago

      I think npm allows installation scripts which do make this worse, as a package can run arbitrary command at install time.

      • anyhow2503@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 day ago

        Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.

    • delcaran@feddit.it
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 day ago

      It’s not, it’s a problem of every package manager that do not use sources and checksums, like rust and python. Take a look at this article that does a better job then me at explaining the situation.

      • Nibodhika@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        8 hours ago

        That article has lots of issues:

        17% of the most popular Rust packages contain code that virtually nobody knows what it does

        That’s not true at all, the article where he got that information from says:

        Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

        So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

        He then lists some ways packages can be maliciously compromised:

        1. Steal credentials and impersonate a dev
        2. Misleading package names
        3. Malicious macros (this one is interesting, had never considered it before)
        4. Malicious build script

        And his solutions are:

        1. Bigger std library (solves none of the above)
        2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
        3. Decentralized packages (which worsens every security concern)
        4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

        Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.

      • arcterus@piefed.blahaj.zone
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        1 day ago

        In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

        17%!

        Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can’t imagine about the long tail which receives less attention).

        Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.

        In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.

        EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.

      • anyhow2503@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 day ago

        The good news is that there already is a gold standard for supply chain security: the Go programming language.

        Lmfao

        • bright_side_@piefed.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          1 day ago

          Competent standard lib + decentralized libs + checksum db.

          While the article is a bit theatralic, it offers important arguments.

          • anyhow2503@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 day ago

            There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.

            • bright_side_@piefed.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              20 hours ago

              Yep you’re right, tampering before transmission is still possible. I think I agree with having a strong standard lib helping that considerably. While the language of the blog is not objective, the “content” was better than expected 😊

      • AnarchistArtificer@slrpnk.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        23 hours ago

        Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this