I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents.
I am wondering if I am missing something obvious here and would value any opinion.
Part of that is the Node / JS ecosystem that churns out libraries for every tiny thing. The Go ecosystem is a lot more streamlined; adding dependencies is frowned upon, building small libraries is frowned upon, etc.
That said, if it's just version bumps then they should be bundled. But what about security issues? Those need to be fixed and updated asap.
How are regular developers going to vet the literally 1000s of Node.js dependencies they rely on?
And who's signing these updates? The package owner? Well, he's the one adding malicious code so he can sign whatever he wants.
I'll say it again, Node.js needs a proper standard library like Go that takes care of common needs most people have. It's been improving but it was a historical mistake to let microdependencies run wild.
Agreed. I'm kind of regretting using Node for my current project. Every time I look at package-lock.json, I die a little. I really like the way Go projects tend to have very few dependencies.
The node ecosystem is built around having third-party dependencies for everything, which makes it impossible to meaningfully vet the code you're running, and once a dependency gets hijacked, all its dependencies are screwed too.
I'm usually the last person to jump to the defense of anything golang related... but people seem to be raising eyebrows about the nodejs dependency. Assuming they're using it for asset compilation etc I really don't see the problem. There's no reason to keep rewriting that stuff in every language.
Security has always been one of my biggest worries when using node. The mentality in the javascript world seems to be to simply not care.
To just use whatever libraries. On all the node.js projects I have worked on, none has had any security aspects when importing a new library. That is a bit scary since many libraries has a ton of dependencies themselves.
Not once have I even heard a discussion about a security topic or perhaps maybe vetting dependencies and similar stuff.
Just these two languages? No other languages or systems have problems with dependencies?
> Caddy, a simple HTTP 2 webserver
Caddy is simple to use, but is not a "simple" server. This is a simple server:
package main
import "net/http"
func main() {
panic(http.ListenAndServe(":8080", http.FileServer(http.Dir("./"))))
}
> Too much modularity and relying on others' work sucks
One of the things caddy implements is automatic ssl support by depending on a library that implements the acme protocol. This type of thing is not exactly simple or something you really want to be writing from scratch if you don't have to.
The problem with node is that there is no such thing as a javascript standard library and javascript tooling is not great at dead code elimination. This results in many trivial libraries that each contain a single function. Once the tooling gets better at dead code elimination there should be fewer larger libraries.
Node js has ridiculously large dependancy trees. There is is this joke that a hello world program in NodeJS is only complete when it has 200 dependancies. If one of those many npm modules has a backdoor/vulnerability then you are screwed which is not the case for other languages.
I think a big problem with the node ecosystem is the lack of standard library. When I'm developing on PHP, Python, or go, they have a vast standard library that means the likelihood of me using a third-party package is relatively low for the most mundane stuff. Comparing that to node, and you'll need to use an npm package for just about anything. This automatically gives you a much larger attack surface. If I understand correctly Deno is supposed to address that, but I have yet to play with it, so not sure how it works.
Congratulations on open sourcing this. It looks great. Is there a reason you went with Node.js instead of something like Go? As a sysadmin, I personally hate having to deal with dependencies from tools built in non-compiled languages like Python, Node and Ruby.
The "node.js" way of doing things, and it's dysfunction, is nearly exclusive to node because Javascript lacks a standard library and npm's haphazard way of running things. Java, Ruby, Python, even my grandfather's Perl have had "modules" for years with none of the fear that is typically associated with Node.
Personally, C++ aversion to sane dependency management is more about C++'s "I know better than you" culture and legacy cruft (packages are usually managed by the distro, not the language) than actually having any serious security implications.
Why not a secure runtime on Golang instead? just curious since I saw in another article here today that the author of Deno(also the creator of nodejs) prefers Go for server stuff.
Leveraging JS popularity is one reason I can think of.
Technically, other systems are vulnerable to the same. In practice, there's something about the node/js ecosystem that encourages the proliferation of dependencies, increasing the attack surface.
Node is quite bad - it encourages a proliferation of small libraries and remove the needs to move the versions forward. This, in turn, leads to a wasteland of old, unsecure, dependencies in the long them.
As a full-stack web developer, I rely heavily on gulp and Bower (as mentioned in the article), as well as a few other small utilities. I know I wouldn't have to give those up by switching to Go, but at that point, if every dev on the project already needs to have Node installed, why not just use Node?
I am wondering if I am missing something obvious here and would value any opinion.
reply