npm is unsafe*

my life of developer is unsafe

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.

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.

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

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

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

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.

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

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.

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

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.

You missed the point by a mile here theo

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

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.

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.

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.

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.

Few people know about "npm ci"... That's what this misunderstanding boils down to. Everyone is using "npm install", but "npm install" ignores the lock file, while "npm ci" honors it.

the problem is not that you host directly from npm... I dont know a single person that got that confused, why did you spend so much time on it? The problem is that even a simple project can easily have hundreds of dependencies and there is no way you can verify that the source code doesnt contain malware or a backdoor, all it takes is one developer screwing up or getting screwed and push a malicious package that gets included by other projects and remains unnoticed, because seriously, a lot of code is unchecked on npm, and you end up with a malicious app either for your users or compromising your own machine. all it takes is a node js file downloading and executing a binary on your system... Dont pretend this is not an issue, there is a very good reason deno the successor to node went with a very strict permission model, where you have to opt in to things like file system access, etc.