5 ms·
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
by hannob 4y ago
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.
- DrBazza 4y agoI built zellij (rust tmux clone) recently. 193 dependencies that cargo downloaded. When did rust turn into javascript? Are there supply chain attacks in Rust?
- sylvain_kerkour 4y agoYes :) https://kerkour.com/rust-crate-backdoor https://kerkour.com/rust-crate-backdoor
- TAForObvReasons 4y agoFor-profit package managers like NPM touted download and package counts as if they were KPI. Deep dependency trees is the natural result.
- freeqaz 4y agoInstalling 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!
- wikfwikf 4y agoThe complete graph on 1400 nodes only has a million edges.
- Jenk 4y agoThat's ret-conning a correlation. Npm aren't _generating_ packages themselves. The community at large is generating them.
- Nextgrid 4y agoThis is especially a problem in languages which have a chronic lack of decent standard library and everything relies on a third-party package.
- ehnto 4y agoI 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.
- bob1029 4y agoThis 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.
- Jenk 4y agoAs 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.
- bob1029 4y agoAre you claiming that Node/NPM is somehow a less vulnerable ecosystem than .NET/NuGet?
- Jenk 4y agoNope. Next strawman, please.
- wongarsu 4y agoThat'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.