3 ms·
Is it typical in the JS space to include dependencies without versioning? Also, curious: does freezing a version really provide much protection? Shouldn’t a co
by clbrmbr 1y ago
Is it typical in the JS space to include dependencies without versioning?
Also, curious: does freezing a version really provide much protection? Shouldn’t a commit hash be used? (Attacker can change a tag.)
- naugtur 1y agopackages published to npm are immutable. if you pin a version, you get the same exact version as long as MSFT servers are not compromised. Installing from git is not recommended and has more issues than you might think https://dev.to/naugtur/a-phish-on-a-fork-no-chips-52cc https://dev.to/naugtur/a-phish-on-a-fork-no-chips-52cc You are supposed to update packages, even if you use lockfiles (very common) or tools that pin your direct dependencies (renovate etc. not so common) And when you do update, will you read the package and all of its updated dependencies? It's a hard problem with a bunch of tradeoffs. Can be done, with enough attention and tools. Tools include LavaMoat :)
- clbrmbr 1y agoRe: updates: I was just thinking of waiting a few weeks on the updates to allow compromised packages to be discovered.
- naugtur 1y agosocket.dev will find most malware within hours of it being published. with LavaMoat most malware won't work even if you don't detect it.
- whilenot-dev 1y ago> packages published to npm are immutable. Depends how you'd refer to them... tags ("@latest", "@next" etc.) are not immutable and it's best to rely on the checksums in the lock file.
- vel0city 1y agoThe package-lock.json includes a hash of the package, not just a version number which should be immutable.
- whilenot-dev 1y agoTo add to this: the hash in the lock file is the checksum of the published tarball, not the commit hash.
- cluckindan 1y agoAnd then someone runs `npm install` on their CI