11 ms·

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 amoun

• lowdose 7y ago
  TJ Holowaychuk said good bye to node in 2014 and switched to go. So your not the first. https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b https://medium.com/code-adventures/farewell-node-js-4ba9e7f3...
• eitland 7y ago
  There's also Java and .NET for those who want better IDE support, better dependency management (without recursively downloading hundreds of packages), and a more traditional language and more fully featured language. PS: I came to statically typed languages as an adult, I actually disliked those languages before I had the lightbulb moment, so I think I might even be more qualified than everyone who hasn't managed to enjoy both sides ;-)
  • pomhellxml 7y ago
    Whilst the dependency management story on Node, Python is sub-par, it’s not all roses in Java land either with Maven and POM file XML-hell.
    • guipsp 7y ago
      Use Gradle
    • eitland 7y ago
      Actually, again as someone who has some real life experience with a number of different systems, including - pip for Python, - NPM, - Nuget - and Maven (and Ant) Maven is by far my favorite, despite XML. In fact, give how small pom files are and how little you have to deal with them (if you know what you are doing) I find it amazing how many comments I have had to read about "XML-hell" etc.
• nothrabannosir 7y ago
  This holds up if you actually do review all Go dependencies. Times are changing, so all the power to you if you actually review it. Otherwise the advantage will remain a potential, never to be realised.
• marcus_holmes 7y ago
  similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than it needs to be). I was explaining why to a friend, and it appears that no-one takes this threat seriously, not even in secure/financial apps. Like you, I wonder if I'm missing something obvious. Why does the npm dependency trust nightmare give me the screaming heeby-jeebies but everyone else thinks it's all perfectly fine?
  • ncmncm 7y ago
    It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observation, but that does not make it wrong. It is possible that WASM can fix much of this, at the cost of exposing ourselves to what might be extreme risks inherent in WASM itself. And of course, to whatever dependencies are brought in for the language we compile to WASM.
    • galangalalgol 7y ago
      Indeed, rust is a likely wasm choice and it is working on an npm nightmare of its own with crates.io. A blessed crates pack is sorely needed to fill out the intentionally thin stdlib in cases you can't afford a dependency tree 20 layers deep for all the reasons mentione on this thread.
      • steveklabnik 7y ago
        Several people have tried the "blessed crates pack" over the years, but they never gained traction, so people stopped working on them.
      • vmchale 7y ago
        It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.
• seemslegit 7y ago
  "Sure I might be running unreviewed code from dozens if not hundreds of unknown entities on my and my users devices, but it's important not to get caught violating a license !" I've been involved with software development for over 20 years in various capacities, and the npm culture is absolutely the worst in terms of irresponsibility and could be effectively used to argue for the need of regulation of the software industry.
• iforgotpassword 7y ago
  I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whether I'd end up with anything remotely sane (already assuming it doesn't involve any crypto or similarly complex).
  • pas 7y ago
    Modern JS is TypeScript. Also Yarn is very handy. (Fast, simple, correct.) If you need leftPad, maybe just "vendor" it manually.
    • krapp 7y ago
      Modern JS is the current ECMAScript standard. Typescript is not "modern JS", any more than Coffeescript was, any more than the compile-to-js language that will probably replace it in a week. You're confusing the tool for the language the tool operates on, akin to claiming modern C++ is Visual Studio.
      • pas 7y ago
        Not using TS means leaving a lot of useful tools on the floor. The ECMAScript standardization is process is invaluable, after all TS builds upon it. But TS provides a saner subset (and adds a very productive type system), without that I wouldn't touch "modern" JS even with a stick.
        • jannes 7y ago
          What do you mean with TS provides a subset of JS? TS is actually a superset of JS. Quoting the TypeScript website: > TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. https://www.typescriptlang.org/ https://www.typescriptlang.org/
• pas 7y ago
  No, you are basically right, but the number of nodes in the dependency tree doesn't really mean that you really have to review all of those. Usually you end up with a big basket of actual dependent projects, and with some versions for them (which leads to the big explosion of the number of nodes in the dep tree). Naturally it should be easy to specify a whitelist of licenses. (Of course then one has to decide whether to trust the package.json-s.) That said, security review is hard for any ecosystem. Go probably has inherent advantages compared to the JS ecosystem, simply by virtue of being younger, having a real standard library, being more focused (no browser vs nodeJS issues) etc. PS: there are projects that aim to do collaborative audit/review for Rust ( https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev ) there should be something like that for the JS world. also there's the NPM "report vulnerability" feature.
• lmm 7y ago
  Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amazed other ecosystems don't offer the same.
  • enriquto 7y ago
    > Dependencies are cattle, not pets. It depends on your context. Sometimes, dependencies are not pets, but weights on your airplane.
  • anton_gogolev 7y ago
    > There's nothing wrong with having zillions of them... There's nothing wrong until something goes wrong an now you're royally screwed. With zillion dependencies you are at a mercy of zillion maintainers, and none of them has any obligation to you. They can break backwards compatibility in patch releases, introduce subtle behavior changes, steer the project in an unexpected direction or abandon it altogether.
    • codeflo 7y ago
      I’m a bit torn on this. I have most of my experience in the .NET ecosystem, where dependencies are a lot more manageable. However, if something breaks, you’re screwed a lot harder, because it’s not so easy to replace a large library, and there are very likely fewer well-maintained alternatives than there would be on NPM. In total, I find it hard to deny how productive the NPM ecosystem can be, despite my philosophical objections to the way the community is run. Am I crazy here?
      • iSnow 7y ago
        You aren't alone in this. The Node/NPM/JS scene is churning out code and innovations like there's no tomorrow, that's something to admire. What I feel they are missing is a community process to consolidate things. You don't need three generations of ten incompatible solutions for a given problem - after some iterations, things should consolidate into one or two more or less standardized libs that don't break existing code at every damn point release.
• seemslegit 7y ago
  Seems like negative comments about npm are getting shadowbanned here, so let's try again: npm-based software engineering culture is utterly irresponsible and should be viewed as a liability for both a company and its users.
  • brlewis 7y ago
    Please don't post vague flame bait.
  • vmchale 7y ago
    The npm dependency model is a nightmare. All the more shameful given that it's backed by a for-profit entity that charges its users.
• csdreamer7 7y ago
  My biggest issue with the massive dependencies is not licensing or security. Both are important, but there is an even bigger block. My biggest issue is with things in the node ecosystem is breakage, especially React libraries. I was following a NetNinja tutorial series on Youtube. I had to use a Firebase-Redux library for a combined React/Redux/Firebase series. There was a security vulnerability with something down the stack only a few months after the tutorial was out. So to use the updated version I had to use the beta version of a Firebase library which broke the tutorial code despite the library change being a point release like 1.4.0-beta2. Either 1.3.0 to 1.4.0 or 1.2.0 to 1.4.0 would be consider a breaking release for this particular dev. We have a large group of dependencies chained upon each other with maintainers that have different support commitments and styles. React might be the de facto JS system, but it relies on a large system of these 3rd party packages to do deeper functionality which can so easily break things. I already had to peg React itself to an older version to use this tutorial when it was months old. I realized at this point how much of a pain it would be to maintain this code in my portfolio if I did something with it. Let alone a paid product. I stopped learning React at this point (or at least learning React+Redux+Firebase). Ruby sorta has this issue too, but it feels the Node ecosystem is much more accelerated. The Rails framework dominates the gem ecosystem so much usually gems break functionality by the version of Rails they support. So gems often will not update or warn of breaking changes based on the Rails version or ActiveRecord which follows Rails versioning. This makes gem dependencies much more manageable. The node ecosystem does not have a large dominating framework like Rails. Even if you considered React that framework, Facebook breaks it whenever they please. 16.4 which sound like a minor version update break things. While Rails 4.2 was supported for 4 years. jQuery might be years before it breaks support.
• baby 7y ago
  Rust is on this path as well, the small standard library pretty much forces people into using a ton of tiny dependencies. Compiling a rust project is exactly like using npm and seeing a never ending list of deps
  • gardaani 7y ago
    It is also difficult to know which dependencies have unsafe code. There's good discussion about it on reddit: https://www.reddit.com/r/rust/comments/ekpa3i/is_anyone_concerned_about_this_deep_deep_nesting/ https://www.reddit.com/r/rust/comments/ekpa3i/is_anyone_conc...
  • matheusmoreira 7y ago
    The underlying problem is the lack of curation. Micro-dependencies that are widely used and have been reviewed for quality should be promoted to a group of standard packages. They'd still be dependencies like any other but they'd be officially maintained and installed by default. Another problem with npm: every package gets its own copy of its dependencies. Not sure if Rust does that.
    • steveklabnik 7y ago
      Cargo de-duplicates packages as much as possible, and only includes multiple copies if there are multiple incompatible versions required.
    • vmchale 7y ago
      > every package gets its own copy of its dependencies. Not sure if Rust does that. It does something halfway in between, which is still a security liability.
  • vmchale 7y ago
    IMO the main problem with Rust is that it's tied to cargo, which tries to link in multiple versions of the same crate.
• danShumway 7y ago
  I don't think the NPM ecosystem is in a great security position, but the pushback I'd make here is that you should be reviewing your Go dependencies as well. If you're looking at the NPM ecosystem and saying, "the number of dependencies is problematic because it takes a long time to review them", I agree with you. If you're looking at the Go ecosystem and saying, "there are fewer dependencies, so I don't need to review them", then that's a security antipattern. The better way to phrase this to your team is that you need to review dependencies, period. The NPM ecosystem isn't problematic because it introduces a new requirement to review dependencies, it's problematic because reviewing dependencies is harder. You can use NPM all you want for security-sensitive code. You just have to spend the extra time to review dependencies, which means bringing in new dependencies will be much slower than in a shallower ecosystem like Go's. That's the point of OP's article. You can't skip reviewing dependencies in any ecosystem, in part because all of our ecosystems across the board have crap sandboxing and permissions, but also because of license issues and quality issues like the author found. There is no shortcut for that, whether you're using Ruby, Go, Python, whatever. You have to review your dependencies.
  • TAForObvReasons 7y ago
    "the number of dependencies is problematic because it takes a long time to review them" The dependencies themselves are generally smaller and more self-contained. Arguably it is easier to review since the side effects and cross-module behaviors are much more pronounced (it's generally deemed a "bad thing" by the community for modules to make unnecessary global actions)
  • jen20 7y ago
    I read the GP post as saying that having fewer dependencies makes reviewing them easier, not that one need not review them?
    • danShumway 7y ago
      My point being that "NPM is bad for security" is probably the wrong take to convince a software team to avoid the ecosystem. Instead, phrase it as, "well obviously we need to review our dependencies, so why use an ecosystem where that's hard?" Don't phrase it as a security problem, phrase it as a development time and overhead problem. Or better yet, let your team use NPM as long as they review the dependencies, and if your dependency tree is really a problem, your team will naturally become annoyed by the extra work and will avoid large dependencies on their own without a lot of extra prompting.
• vmchale 7y ago
  > Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. The npm model is a shitshow (multiple versions of one dependency). People defend it for obviously self-interested or lazy reasons.
• SkyBelow 7y ago
  >Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. This seems to apply to security in general. Security these days is doing the minimum amount needed to check some boxes that you are now secure. I suspect a lot of this is driven by incentives. There is few negatives to an individual to use bad security over good security, and the costs of good security means less of the 'good stuff' being developed which results in worse reviews and less prestige. And if people are hacked, the blame is primarily placed on the hackers with little danger to the developers and often even less danger to the company (they might have to spend 5% of the budget they saved on PR to repair their image). I'm not sure how to fix the issue with prioritization of security. My first guess would be by changing the incentives to companies so they bear the liability in identity theft instead of the user (the very concept of identify theft is a trick to blame the end consumer instead of either the business leaking data or the business giving away money without verifying if data is accurate).
• ljm 7y ago
  They both have flaws. NPM due to the cascading mass of transient dependencies; go (historically) due to pulling dependencies from the master branch of a repo. All of those can change from underneath you. In any case you can’t avoid proper auditing and pen-testing. Even if your app code is rock solid, it doesn’t mean your infrastructure is safe. Or even your office building or the data centre serving the code. Or your employees and their credentials. All it takes is a decision to use mongodb or redis without auth and to expose the ports to the internet, and the most secure runtime in the world won’t save you then. Or a bit of social engineering so the attacker is making perfectly legit requests in your perfectly secured app.