Hacker News Reader

Comment by hannob | Hacker News Reader

The answer is "too many dependencies".

Package manages made it easy to have dependencies. Every added dependency adds risk. That doesn't mean you should never add dependencies - there are good reasons to do so - but you should weight their pros and cons. Adding dozends, hundreds or thousands of dependencies (as it is common in the npm ecosystem) adds lots of risk. None of that is particularly surprising.

View on HN

This is the #1 reason we use .NET for our banking apps. Everything we need is baked into the Microsoft-owned dependencies. Certainly, you could argue of transitive attacks still being possible but from a liability perspective we get to point our finger at Microsoft if something goes wrong (while we hastily rebuild with their patch)

Even for my side project - building a custom 3D rendering engine from scratch - I use libraries like System.Numerics to calculate the camera perspective transform and perform all the linear algebra for me. I was wasting a lot of time trying to reinvent this, which is a typical but lethal risk to any project.

As head of eng in a ftse100, this is so far from the truth. .Net is a heavily targeted ecosphere, possibly moreso than npm, precisely because of its relation with finance.

We have to contend with not only nuget and the sheer abundance of packages available (with their own transitive dependencies similar to the problems with npm - yes, even Microsoft packages have this risk) posing problems, but also the tooling itself.

VS/Code is a fucking minefield of potential threats. Their extensions market place(s) are automatic RCE risks, and a developer/admin/whomever box getting pwned is a monumental risk.

Zero-Trust applies to everyone and everything. Microsoft don't get a pass just for being Microsoft.

Are you claiming that Node/NPM is somehow a less vulnerable ecosystem than .NET/NuGet?

Nope. Next strawman, please.

That's not what they said. They said .NET/NuGet shares some of the problems NPM has, and that it's targeted more because it's a juicer target.

That doesn't mean it's more vulnerable, but it means it has to be less vulnerable to offer the same security. To offer a bad analogy: if a bank vault was as vulnerable as my fridge, people would constantly break into the bank vault but keep ignoring my fridge.

Your reply is very uncharitable. Newer versions of .NET rely on next to zero non-Microsoft dependencies. The most notable exception to this used to be Newtonsoft.Json, which has since been replaced with Microsoft-owned System.Text.Json. You can easily implement very complex business applications with app stacks like ASP.NET or WPF while relying on exactly zero non-Microsoft dependencies.

The GP never said Microsoft "gets a pass." They were pointing out that there are stacks like .NET where reliance on third-party unvetted libraries is greatly reduced if not eliminated outright. Additionally, nearly all businesses run Windows anyway, so using Visual Studio and Visual Studio Code are not the risks you make them out to be. Centralized Active Directory policies already help guard against rogue extensions and such, assuming IT even cares (they nearly never do in my experience).

Yes, the surface area threat of .NET and NuGet is far, far lower than that of NPM for nearly all apps.

This is especially a problem in languages which have a chronic lack of decent standard library and everything relies on a third-party package.

For-profit package managers like NPM touted download and package counts as if they were KPI. Deep dependency trees is the natural result.

Installing react-scripts is ~1400 dependencies and around 2 million "edges" (where one package requires another). This blew my mind recently when "yarn audit" was failing with an OOM error!

The complete graph on 1400 nodes only has a million edges.

Clearly these dependencies are bidirectional. :P

It depends on the version of React Scripts. Newer ones are better, but ~3.4.4 is around 2m edges with the JS library we're using to parse it out.

Regardless, I was very surprised that it could be 7 figures!

That's ret-conning a correlation. Npm aren't _generating_ packages themselves. The community at large is generating them.

I would wager that the PHP standard lib isn't all that comprehensive, but it doesn't suffer anywhere near as much from nesting dependencies. I think the culture is that a library takes care of itself for the most part.

I built zellij (rust tmux clone) recently. 193 dependencies that cargo downloaded. When did rust turn into javascript? Are there supply chain attacks in Rust?

Yes :) https://kerkour.com/rust-crate-backdoor

Reply on news.ycombinator.com