971–980 of 1001 posts
Blog author company's runner detects anomalies in them, but we shouldn't need a product for this. Detecting outbound network connection during an npm install is quite cheap to implement in 2025. I think it comes down to tenant and incentives, if security is placed as first priority as it should, for any computing service and in particular for supply chain like package management, this would be built in. One thing tha…
"Outbound network connection at npm install" is just one of many ways malware in NPM package can manifest itself. E.g. malware might be executed when you test code which uses the library, or when you run a dev server, or on a deployed web site. The entire stack is built around trusting a code, letting it do whatever it wants. That's the problem.
Earlier quoted context omitted.
`npm install` uses a lockfile by default and will not change versions. No, not transitives either. You would have to either manually change `package.json` or call `npm update`. You'd have to go out of your way to make your project as bad as you're describing.
A lot of people use tools like Dependabot which automates updates to the lockfile.
As well, both Dependabot and Renovate in isolated environments withour secrets or privileges, need to be manually approved, and have minimum publication ages before recommending a package update to prevent basic supply chain attacks or lockfile corruption from a pinned package version being de-published (up to a 3 day window on NPM).
Earlier quoted context omitted.
`npm install` uses a lockfile by default and will not change versions. No, not transitives either. You would have to either manually change `package.json` or call `npm update`. You'd have to go out of your way to make your project as bad as you're describing.
No, this is just wrong. It might indeed use package-lock.json if it matches your node_modules (so that running `npm install` multiple times won't download new versions). But if you're cloning a repo off of GitHub and running npm install for the first time (which a CI setup might do), it will take the latest deps from package.json and update the package-lock.json - at least this is what I've found many responses onlin…
The way you describe it working doesn't even pass a basic "common sense" check. Just think about what you're saying: despite having a `package-lock.json`, every developer who works on a project will get every dependency updated every time they clone it and get to work?
The entire point of the lockfile is that installations respect it to keep environments agreed. The only difference with `clean install` is that it removes `node_modules` (no potential cache poisoning) and non-zero exits if there is a conflict between `package.json` and `package-lock.json`.
`install` will only update the lockfile where the lockfile conflicts with the `package.json` to allow you to make changes to that file manually (instead of via `npm` commands).
Earlier quoted context omitted.
Well but the docs you cited don't match what you stated. You can delete node_modules and reinstall, it will never update the package-lock.json, you will always end up with the exact same versions as before. The package-lock updating happens when you change version numbers in the package.json file, but that is very much expected! So no, running npm install will not pull in new versions randomly.
The internet disagrees. NPM will gladly ignore and update lock files. There may exist a way to actually respect lock files, but the default mode of operation does not work as you would naively expect. - NPM Install without modifying the package-lock.json https://www.mikestreety.co.uk/blog/npm-install-without-modif... - Why does "npm install" rewrite package-lock.json? https://stackoverflow.com/questions/45022048/why-…
2&3. NPM 5 had a bug almost a decade ago. They literally link to it in both of those pages. Here[^1] is a developer repeating how I've said its supposed to work.
It would have taken you less work to just try this in a terminal than search for those "citations".
[^1]: https://github.com/npm/npm/issues/17979#issuecomment-3327012...
Earlier quoted context omitted.
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
> Standard libraries should include everything needed to interact with modern systems. This is great when the stdlib is well-designed and kept current when new standards and so on become available, but often "batteries included" approaches fail to cover all needs adequately, are slow to adopt new standards or introduce poorly designed modules that then cannot be easily changed, and/or fail to keep up-to-date with the…
Earlier quoted context omitted.
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
> Standard libraries should include everything needed to interact with modern systems. This is great when the stdlib is well-designed and kept current when new standards and so on become available, but often "batteries included" approaches fail to cover all needs adequately, are slow to adopt new standards or introduce poorly designed modules that then cannot be easily changed, and/or fail to keep up-to-date with the…
Really, good stdlib still allows you to use better suited 3rd party libraries. Lack of good stdlib doesn't add anything.
Earlier quoted context omitted.
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
> This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. > Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. There is another way. Why not make the standard library itself pluggable? Rust has a standard library and a core library. The sta…
It works well, but the downside of that approach is people complaining about how abstract things are.
Earlier quoted context omitted.
> That's exactly npm's problem, though. I don't think that's the problem with npm. The problem with npm is that no packages are signed, at all, so it ends up trivial for hackers to push new package versions, which they obviously shouldn't be able to do.
Since Shai-Hulud scanned maintainers' computers, if the signing key was stored there too (without a password), couldn't the attackers have published signed packages? That is, how does signing prevent publishing of malware, exactly?
Yeah, of course. Also if they hosted their private key for the signature on their public blog, anyone could use it for publishing.
But for the sake of the argument, why don't we assume people are correctly using the thing we're talking about?
Earlier quoted context omitted.
LLMs don't copy and paste. They ingest and generate. The output will always be a generated something.
In 2022, sure. But not today. Even something as simple as generating and running a `git clone && cp xyz` command will create code not directly generated by the LLM.