Hacker News Reader

Comment by 0des | Hacker News Reader

Stdlib or die. You did this to yourself by trusting strangers for your laziness.

"Its just a package for X" until its not.

Yes.

I checked out a small project recently and it had over 2000 nom packages as dependencies. The culture around node development was/is just too dependency happy.

I get standing on the shoulders of giants and that not all people are bad, but with thousands of dependencies, the chances of a supply chain issue starts to become significant.

Most people are good, but because destruction is so much easier than creation a few people can destroy what it takes a lot of people to build. For example it will take Ukraine months just to dig the bodies out the destroyed family homes that Russia spend a few minutes bombing.

However I don't think the number of dependencies is a useful number: node was one of the first languages to have a build in standard way to get and manage dependencies, which meant that dependencies could be much, much smaller. Boost for C++ is a giant project, so you can say that your C++ project only has a few dependencies, but if C++ had a decent standard dependency manager, projects like Boost were probably split up more.

* I am aware Maven exists for Java, but the cultural expectations for Java were set long before it became a thing.

> node was one of the first languages to have a build in standard way to get and manage dependencies

CPAN? Pip in python? Pear for php?

Bundler for Ruby, maven for Java, ...

Most people are good

incorrect, try again please.

Until something bundled with a large amount of linux distros has a root privilege escalation[1].

[1] https://access.redhat.com/security/vulnerabilities/RHSB-2022...

Aren't bugs different than malice? I sure hope so or I'm in a tight spot.

My main point was that it's silly to treat stdlibs as gospel and everything else as vulnerable nonsense.

So… no more open source?

>So… no more open source?

No more random-source. And no more "automatically pull from master, then build & deploy".

Well, maybe no more "pull someone else's master and build without scanning".

Inside a walled garden / from specific people you trust should be fine. Some automated scanning could maybe be ok-ish at least sometimes.

This is why I commit node_modules to my own repos.

Unless you are reviewing the code in your assumedly large bundle of dependencies there, this is not a solution if you weren't posting this in jest

Not in jest. Still using node_modules from before these stunts started to occur. I recognize I am accepting risk. What I am avoiding is the surprise of a ^version-compatible file introducing new and unwanted “features”.

What do you do for security updates? There are a lot of them for NPM modules. Seems GitHub manages the database for those now:

https://github.com/advisories

I swear 99% of them are prototype pollution or regex DOS that don't apply to how I'm using the dependency.

What about the 1% that delete data or allow for code execution?

See, now I can only assume you are playing with our emotions. You got the forehead vein going at first though so I'll give you that.

Snapshot VM, npm install

And how do you know that is safe and hasn't exfiltrated all your data or used a VM escape exploit.

Even then, if undocumented functionality is waiting for a certain day or certain action for something to execute you have no way in asserting one way or the other if it is safe because you haven't reviewed it.

Just pipe curl to bash ;)

Nope, just a smaller circle of trust.

Vet and pin your dependencies.

Seems like overkill. You can just pin the version of the dependency and host it, no? It’s standard practice the last few places I’ve worked.

Unless you are reviewing their code too then it is no different. I've read every privacy policy and TOS I've ever signed and even I can't fathom reviewing node modules to completion. I don't even know if that is possible given that any node project can have endless cyclic dependencies

I have worked at a big famous tech company where you had to have approval for every dependency. It was slow to get a new library reviewed, but usually the popular ones were already on the list. I think this process actually scales reasonably well because the more engineers you have, the more likely it is someone else has been there before.

Reply on news.ycombinator.com