Comment by jxcole | Hacker News Reader

Comment by jxcole | Hacker News Reader

It's a little ridiculous to view this as a problem. I am currently working on a small personal project in my spare time with 775 dependencies. Quickly perusing the dependencies the reason there are so many is because I am using:

* Webpack

* Unit testing (Mocha)

* Code coverage (Istanbul)

* Browser transpilation (Babel)

* Type safety (typescript)

Now for an apples to apples comparison I used to work on c#/.net. Complaining about these dependencies would be akin to me complaining that I couldn't manually audit the unit testing dlls that VS is using to do code coverage for me. Of course, no one ever audits these DLLs. A more interesting analysis is to look at how many non-dev dependencies you have (I have none, I doubt this basic react package has more than just react for the production code).

Of course one could argue "someone might stop maintaining this project", but this is equivalent to saying "I won't use open source". In fact, in my experience the opposite is true, with closed source paid software becoming obsolete more regularly than open source alternatives. If a company decides something isn't making money they will usually can it while with open source at least someone has the opportunity of picking it up when an author loses interest.

Dev dependencies are as dangerous as production dependencies and always have been. Read this from 1984: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...

Those 1,568 create-react-app dependencies are maintained by people you have no formal relationship to, and are all versioned independently. Visual Studio is one monolithic package released by one of the largest companies on earth. Microsoft is not going to back door you and it has a huge incentive to stop anyone else from directly back dooring you via Visual Studio. On the other hand, the maintainer of the event-stream NPM package, with ~1.5 million weekly downloads, recently gave control to a stranger. They successfully back doored it and evaded detection for over a month. https://blog.npmjs.org/post/180565383195/details-about-the-e...

Is that any less true for completely unrelated pieces of software on the same machine? If you have a nice secure monolithic .NET project on your machine, and you also ran a create-react-app project on the same machine, shouldn’t you be just as worried?

Not really, at least IMHO. Not every vulnerability in [insert unvetted react dependency here] contains a host-targeting malware payload. In fact, I'd imagine those are the minority. Some concern is certainly warranted though.

now with the nuget ecosystem VS projects also depend on external dependencies you have no formal relationship to

That's a different issue. I was replying to the claim that Visual Studio itself vs. create-react-app itself is an "apples to apples comparison" (their words).

yep. In theory a dotnet project pulling in nuget packages is in the same class as a node project pulling in NPM packages.

In practice, it's tremendously different.

As mentioned, a do-nothing react app has 1500 dependencies, all managed by who-knows-how-many different companies and individuals

A do-nothing aspnetcore app has maybe a few dozen dependencies, and with the exception of Newtonsoft.JSON, all of these are managed and supported by Microsoft.

When you scale that up to a real app, I don't even know what you get with Node/npm? 2500 dependencies? With aspnetcore you probably end up adding 10-20 more dependencies, and some of them are probably written by Microsoft.

So, your "potentially untrustworthy package count" in node is about 2000 packages, whereas for aspnet it's about 10 packages. You can review and pay attention to 10 packages. 2000? Not so much

Aside: A java/maven project probably falls somewhere in between, but closer to the aspnet scenario. Instead of a few dozen dependencies you might have 50, but it's still realistically possible to review them all, and they're far more likely to come from trusted publishers such as the Apache foundation.

I think the "package count" is perhaps a bit of a red herring. IMHO the "publisher count" is more important.

I don't care if there are 700 packages if they all come from the Apache Foundation. I trust the Apache foundation and as such they can be considered one "block" when it comes to reviewing their chance of releasing a malicious/hacked package.

Visual studio is basically ONE package from ONE publisher Internally it's made up of thousands of tiny components, and includes third-party open source software such as Newtonsoft.JSON, but Microsoft is responsible for vetting all that stuff, and they do.

The problem with the JS ecosystem is that many of the packages come from all over the place. For example, create-react-app depends on envinfo which is published by "Trevor Brindle". It also wants cross-spawn, from "André Cruz", chalk from "Josh Junon", Commander.js from "abe tomo", fs-extra from "JP Richardson", this list goes on and on.

Who are all these people and are they all trustworthy? I don't know, I can't tell, and neither does anyone else, which is the core problem.

Well with .net it's usually less than 10 of dlls (not counting .net framework itself, though it may have increased in several years). As opposed to npm, where webpack itself may need 3-5 packages (css loader, url loader, etc), not counting their dependencies.

But I'm not saying it's better or worse, just different. But for sure it's harder to audit.

Reply on news.ycombinator.com