npm is unsafe*

People seem scared about NPM's safety. I think that's kind of silly. Decided to explain why I feel that way. And yes, thumbnail is a @LowLevelTV shoutout

S/O Ph4se0n3 for the awesome edit 🙏

[nikomitk]

15:30 I think you kinda misunderstood, what many people are worried about. It's not, that known good packages (like react) get compromised, but that you don't really know what many dependencies do. Maybe that small utility package used to add some spaces to the left of your string also has code to send every keystroke to some server and grab the passwords of your user. Nobody is looking at the code of the hundreds of packages many projects include.

[BalintCsala]

My favourite case of loading js from other websites is still barclays UK loading a js file from an older waybackmachine copy of their own website.

[viccie]

It feels unsafe when I go npm install on a project where my colleagues and I are working on and it installs a multitude of dependencies because we don't just use plain react and react-dom. We use other packages which do have a bonkers dependency graph. That then installs 1500 packages with multiple vulnerabilities which you can't fix because they are multiple dependency levels deep and those packages that depend on the vulnerable packages sometimes depend on specific versions so you can't just go all willy nilly and update all the vulnerable packages because you might break your entire appllication. That is something that feels unsafe

[krumbergify]

It is not about NPM as such, it is about having too many unreliable dependencies. In C/C++ dependency management used to be hard so historically people tried hard to keep their dependencies few and small.

[MaximoJoshua]

I'm surprised that no one has mentioned that his dependency versions are not "locked", you know that the ^ means that you can automatically download ANY new minor or patch version...

so in this example, you can download react 18.4, 18.3.2, 18.5...etc

if you actually want to lock the version, you have to remove the ^

its all in the documentation on semver

in practice, its also better to set up your own private npm which proxies the public one, solutions like nexus can do this automatically for you, so you can host your packages and still get all the packages from the same URL

[browny]

Just the fact that npm audit has to exist proves you wrong. We cannot keep track of the thousands of left-pad, is-number and similar packages, so we have to build a workaround for it.
"Back in the day" you had a database wrapper like pdo, and maybe some Apache modules like Headers, Session etc. and that was it. Easy to keep track of and less points of failure.
I think this is an issue with js in general, because so little needed functionality is built in and the trivial code is usually very flawed because of some edgecase.
In other modern languages like C# you usually only need 2-10 nuget packages for a large project and even then most are provided by Microsoft.

That’s my issue with JavaScript and its ecosystem.

[saryakan]

The secret:
It's unsafe all the way down.

[chris]

Your screen at 3:56 shows the thing that really stresses me out about npm; everything you download throws up twelve thousand warnings about how there's something wrong with it. And I'm a noob, what do I know, it usually works anyway and tutorials all act like that's normal, so I learned to just ignore it, but it feels like learning to ignore an overreactive smoke alarm.

[THENP]

Honestly the biggest risk with npm is the near heart attack when you have a typo in a package you npm install and it downloads a package with 19 total downloads

[llamasaylol]

Slight disagreement on Theo's take on dev dependencies not being as much of a risk (as regular dependencies). Having to hijack the build step vs being conveniently bundled is a trivial difference for a malicious author.

[muB]

I don't think you even understood their worries here. You still remember the xz backdoor, right? I've seen projects relying on random hobbiests' repo. Not that those hobbiests are doing a bad job. The problem is that you have no idea what level those devs' securtiy awareness are at. Offensive operators will focus on the weakest link, and it's a disater when even experienced devs have no idea where the weakest links are at.

[deku_nattsu]

don't try checking the dependencies of react-native on npmgraph 💀

[doingwell]

It doesn't matter if the npm server itself is "safe." What matters is the number of maintainers of those packages you depend on. At ANY moment, ANY number of them can go full evil mode and start pushing malware into the package they control.

[AbstractObserver]

You missed the point by a mile here theo

[Kotfluegel]

The bundler doesn't distinguish between dependencies and devDependencies. Using devDependencies does not exclude those deps from being shipped to the user. The bundler ships everything to the user that is referenced from your source files.
Rather, devDependencies controls what is being removed on "npm prune --production" from your node_modules directory. That is important for node apps without bundling since the require function in commonjs will load js files from your node_modules folder.
But if you bundle your apps, you might as well just have everything be dev dependencies, since your dependencies' code will be *bundled* into your build artifact anyway.

[pokefreak]

Literally no one thinks npm can somehow pwn your website at runtime, the point is that you're downloading and executing dozens of megabytes of arbitrary code on your machine.
You're not safe just because there's no active NPM scandal, literally open any year old project and NPM will automatically warn you about a dozen new security vulnerabilities that were discovered, it's safe to assume there are dozens more that have not been reported yet and are actively being exploited by malicious actors.
And why assume devdeps are safe? If a package like eslint got compromised it could trivially inject malicious code into your bundle. Just because it's supposed to only run on your machine doesn't mean it can't still access files in your dist folder.

[svenmify]

It’s not only about what’s unsafe for your users. You are basically opening up your file system to unknown entities, so it’s unsafe for you. Whenever you run a script locally, there’s so many scripts that you don’t know about that now have access to your files.

[doingwell]

"Getting always the same thing" is not about security, it's integrity.
Unsafe package can pass integrity check and still to be unsafe.

[PrivateNaelyan]

Perspective of a new dev who who just did a basic training course and a few personal projects, so pretty much a baby with not much knowledge yet.

The concept of using cdn has something that have felt crazy to me from the first time i heard about it and i never want to use any forein cdn in any of my projects.

I do consider package managers due to lock versions which will prevent automatic updating to newer versions with possibly security issue and that is certainly a major step in securing the depencies overall.

But the constant fear lurking in the back of my head is that this just protect from the introductions of future security issues, in all cases we are still adding dependencies in an effort to not waste time reinventing fire for every use case. That means we add a lot of foreign code and among that sea of dependencies there may be some code that has been cleverly hidden for malicious use and not found yet. It gives the feeling that a decent chunk of the ecosystem is built on trust, and trust is a very expensive commodity in our era.

[ZombieJig]

Dependencies are unsafe. If you care about security you pick a stack without a deep dependency hierarchy.