Comment by daotoad

2 years ago

TLDR:

1. a cryptocurrency scheme for funding OSS development[1] is incentivizing spammers to try and monetize NPM spam

2. it's easy to spoof your dependencies with package.json[2]

  "dependencies": {
    "axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz"
  }

[1]: https://tea.xyz/blog/the-tea-protocol-tokenomics

[2]: https://www.npmjs.com/package/sournoise?activeTab=code

A "better" way is to modify the package-lock.json. You can still spoof the package but almost no one actually reviews it as npm will usually modify 1000s of lines.

for example take mongoose

      "resolved": "https://registry.npmjs.org/mongoose/-/mongoose-8.4.4.tgz",
      "integrity": "sha512-Nya808odIJoHP4JuJKbWA2eIaerXieu59kE8pQlvJpUBoSKWUyhLji0g1WMVaYXWmzPYXP2Jd6XdR4KJE8RELw==",

so long as the integrity check passes for the resolve url npm will happily install it.

  • Hugely surprising that package.json and package-lock.json don't have to match. The way I would expect it to work is something like:

      for d in dependencies_from_package_json()
        get_package(d)
        if hash_package(d) != package_lock_hash(d)
          error()
        end
      end
    

    And not:

      use_package_lock_and_ignore_package_json_lol_fuck_you_haha_kthxbye()
    

    I also discovered that npm doesn't actually verify what's in node_modules when using "npm install". I found this out a few ago after I had some corrupted files due to a flake internet connection. Hugely confusing. Also doesn't seem to be a straightforward way to check this (as near I could find in a few minutes).

    But luckily "npm audit" will warn us about 30 "high severity" ReDos "high impact" "vulnerabilities" that can never realistically be triggered and are not really a "vulnerability" in the first place, let alone a "high impact" one.

  • That (and anything else relying on the lockfile) won't take effect for users who install the package from the npm registry, unlike changes in package.json.

Re 2: How is that "spoofing"..?

You just demonstrated the uglier package-manager-independent overrides(npm)/resolutions(yarn) aliternative method. Because for whatever reason they couldn't play nice with each other.

npmjs.com seems to be interpreting the field incorrectly but 1) AIUI that does not affect actual npm usage, 2) If you rely on that website for supply-chain-security input I have bridge to sell... Basically all the manifest metadata is taken as-is and if the facts are important they should be separately verified out-of-band. Publishers could arbitrarily assign unassociated authors, repo URL, and so on.

https://docs.npmjs.com/cli/v9/configuring-npm/package-json#o...

https://classic.yarnpkg.com/lang/en/docs/selective-version-r...