3 ms·

I know that node has `package-lock.json` and `yarn.lock`, which include integrity checks. Are these checks decorative only? How could npm have been affected by

I know that node has `package-lock.json` and `yarn.lock`, which include integrity checks. Are these checks decorative only? How could npm have been affected by this issue?

nstart 6y ago
IIRC you need to use npm ci to ensure that package-lock.json is used. That said, when developing locally you are going to use npm install or npm update and update the package.json and package-lock.json files accordingly. I could be entirely off target here since I'm writing purely from memory. But there seems to be a few different ways one could trigger a pull from the malicious repo and end up with it inside the package-lock.json file
- nickkell 6y ago
  I feel stupid for using npm for so long without knowing about this command. In hindsight it's obvious that install was updating the lock file each time, so why should it have been any different on the ci server?
- K0nserv 6y ago
  No that's not correct, in fact this comment and the two sibling comments are both wrong. Quouting from NPMs documentation[0] for npm install > This command installs a package, and any packages that it depends on. If the package has a package-lock or shrinkwrap file, the installation of dependencies will be driven by that, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm Consider an example where in package.json you have `"react": "^16.11"` and this has been resolved and fixed in package-lock.json as 16.12 at a previous point in time. Running npm install will not cause NPM to install 16.14 even though it matches the pattern specified in package.json, instead 16.12 will be installed because that's what package-lock.json says. What npm install does do, is detect if you've made changes in package.json and only then does it re-resolve the dependency. In the above example, if you changed `"react": "^16.11"` to `"react": "^16.14"` in package.json and then ran npm install the package-lock.json would be changed and version 16.14 would be installed. Bundler and CocoaPods also work this way.
matsemann 6y ago
The final build would probably have failed (on a build server using CI). But when developing locally I think package.json wins over the lock file (? at least often the lockfile is updated after doing an npm install here). So this probably wouldn't show up on the final build distributed and deployed somewhere. But it did manage to run arbitrary code on developers' machines of those companies.
raihansaputra 6y ago
You can easily misconfigure npm by using the `npm i`/`npm install` command on CI/CD instead of `npm ci`. `npm install` does not take any lockfiles into account and only uses the package.json and upgrades any package/dependency that is not pinned.

I know that node has `package-lock.json` and `yarn.lock`, which include integrity checks. Are these checks decorative only? How could npm have been affected by this issue?

nstart 6y ago

IIRC you need to use npm ci to ensure that package-lock.json is used. That said, when developing locally you are going to use npm install or npm update and update the package.json and package-lock.json files accordingly. I could be entirely off target here since I'm writing purely from memory. But there seems to be a few different ways one could trigger a pull from the malicious repo and end up with it inside the package-lock.json file

nickkell 6y ago
I feel stupid for using npm for so long without knowing about this command. In hindsight it's obvious that install was updating the lock file each time, so why should it have been any different on the ci server?
K0nserv 6y ago
No that's not correct, in fact this comment and the two sibling comments are both wrong. Quouting from NPMs documentation[0] for npm install > This command installs a package, and any packages that it depends on. If the package has a package-lock or shrinkwrap file, the installation of dependencies will be driven by that, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm Consider an example where in package.json you have `"react": "^16.11"` and this has been resolved and fixed in package-lock.json as 16.12 at a previous point in time. Running npm install will not cause NPM to install 16.14 even though it matches the pattern specified in package.json, instead 16.12 will be installed because that's what package-lock.json says. What npm install does do, is detect if you've made changes in package.json and only then does it re-resolve the dependency. In the above example, if you changed `"react": "^16.11"` to `"react": "^16.14"` in package.json and then ran npm install the package-lock.json would be changed and version 16.14 would be installed. Bundler and CocoaPods also work this way.

matsemann 6y ago

The final build would probably have failed (on a build server using CI). But when developing locally I think package.json wins over the lock file (? at least often the lockfile is updated after doing an npm install here). So this probably wouldn't show up on the final build distributed and deployed somewhere. But it did manage to run arbitrary code on developers' machines of those companies.

raihansaputra 6y ago

You can easily misconfigure npm by using the `npm i`/`npm install` command on CI/CD instead of `npm ci`. `npm install` does not take any lockfiles into account and only uses the package.json and upgrades any package/dependency that is not pinned.