← Back to context

Comment by vorticalbox

2 years ago

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.

12 comments

vorticalbox

Reply
arp242  2 years ago

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.

  • tyingq  2 years ago

    I think that's true for most package managers. That if there's a lock file, there's typically a default command to use it for installs and ignore the main config file.

    • arp242  2 years ago

      Yeah maybe, I don't really know off-hand and I'd have to check. I know it's not possible in Go but not sure about anything else. I'd consider it hugely surprising for other packagers where that's possible too. Who is carefully auditing if the repo URL in the lockfile is actually the correct one?

      1 reply →

  • dartos  2 years ago

    FWIW l, I believe “npm ci” is the install command which strictly respects the lock file

  • 3np  2 years ago

    > 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.

    Yeah, you want to be using a tool that lets you ignore/acknowledge specific entries.

    `npm audit` is not an end-all-be-all.

    Like and subscribe[0]: https://github.com/npm/rfcs/pull/18

    https://www.npmjs.com/package/npm-audit-resolver

    [0]: The bottom comment from Jan sums up what happens when Microsoft steps up...

3np  2 years ago

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.