reply on: NPM security: preventing supply chain attacks | Snyk (2022) \ stacker news ~security

pull down to refresh

53 sats \ 18 replies \ @WeAreAllSatoshi 9 Sep \ parent \ on: NPM security: preventing supply chain attacks | Snyk (2022) security

I think that’s right. But really you shouldn’t ever have an incomplete lock file? If you run install and your lock file changes, you have a problem.

50 sats \ 15 replies \ @ek OP 11h

There's so much conflicting information regarding this, online and my own (fuzzy) experience

I also think how @k00b described it is how it should work (it would actually make sense), but I also know that npm install did modify package-lock.json in the past for me.

But maybe that was indeed only when I was working with others and someone forgot to check in package-lock.json after they added it, which would then lead to an incomplete lock file for the next person that pulls.

At this point I guess I have to read the source code of npm to trust what's going on

55 sats \ 12 replies \ @WeAreAllSatoshi 11h

In my experience, installing only modifies the lock file if it's missing information. Because the point of the lockfile is to tell the package manager exactly what to install. It's not like a suggestion - it is the source of truth. It's only changed if it's missing details, or you specifically tell it to install something new and/or upgrade, which falls under the "missing details" broader label.

50 sats \ 11 replies \ @ek OP 11h

Doesn't that imply that everyone who ran npm install and downloaded the malicious version were using an incomplete lock file?

55 sats \ 10 replies \ @WeAreAllSatoshi 11h

Yes? Either they didn't have it in their lockfile, or they installed the dependency new while the malicious version was the latest, or they did an upgrade while it was live.

55 sats \ 9 replies \ @WeAreAllSatoshi 11h

Otherwise, you'd see changes in lockfiles all the time as any number of transitive dependencies are updated within semver constantly.

50 sats \ 8 replies \ @ek OP 10h

Makes sense!

I'm just still confused because the cause doesn't seem to match the amount of confusion. How this can happen (incomplete lock file) doesn't seem to match how often it seems to happen (the internet is full with people complaining about it).

Did all of them also had someone who forget to check in changes to package-lock.json? How else could it happen to have an incomplete lock file? Who modifies their package-lock.json manually or undoes the changes to it (git checkout package-lock.json) and then wonders why npm install changes it again or ...?

But maybe I'm contributing to the confusion around it right now haha

I wish the documentation was more clear when npm install changes package-lock.json. I don't see it mentioning what happens if the lock file is incomplete.

172 sats \ 7 replies \ @k00b 10h

ek is learning that most people suck at their jobs in real time :)

132 sats \ 0 replies \ @WeAreAllSatoshi 10h

ROFL - yep

reply on another page

0 sats \ 5 replies \ @ek OP 10h

but can so many people really suck that much??? lol

you have a point

view all 5 replies

100 sats \ 0 replies \ @0xbitcoiner 11h

Not sure if this has anything to do with what you guys were talking about, but did you see this? #1213980

0 sats \ 0 replies \ @ek OP 11h

after they added it

*after they added an package

166 sats \ 1 reply \ @k00b 23h

Yep, my understanding too

65 sats \ 0 replies \ @WeAreAllSatoshi 23h

It’s certainly still a viable attack vector though, because who checks all of their transitive dependencies every time dependabot opens a PR haha