Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's nothing really specially about the JS ecosystem that creates this problem. Plenty of others could fall in the same way, including C++ (see xz).

The problem is we've been coasting on an era where blind trust was good enough an programming was niche enough.



There's a culture of micro-dependencies.

In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads


That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++.

A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel.

[1] https://www.bleepingcomputer.com/news/security/linux-bans-un...


Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting.

The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies


In practice this means that in C and C++ land you have large framework-style libraries (GLib, Boost, Qt etc), which are much easier to vet, and doing it ones gives you a whole lot of goodies at once with minimal dependencies.


Lower barrier to entry - JS allows newbies to roll up on CodePen and see the result of code without understanding the execution environment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: