6 ms·
Stdlib or die. You did this to yourself by trusting strangers for your laziness. "Its just a package for X" until its not.
by 0des 5y ago
Stdlib or die. You did this to yourself by trusting strangers for your laziness.
"Its just a package for X" until its not.
- yibg 5y agoSo… no more open source?
- krasin 5y ago>So… no more open source? No more random-source. And no more "automatically pull from master, then build & deploy".
- djbusby 5y agoJust pipe curl to bash ;)
- tbrownaw 5y agoWell, maybe no more "pull someone else's master and build without scanning". Inside a walled garden / from specific people you trust should be fine. Some automated scanning could maybe be ok-ish at least sometimes.
- deleted 5y ago[deleted]
- CodeWriter23 5y agoThis is why I commit node_modules to my own repos.
- 0des 5y agoUnless you are reviewing the code in your assumedly large bundle of dependencies there, this is not a solution if you weren't posting this in jest
- CodeWriter23 5y agoNot in jest. Still using node_modules from before these stunts started to occur. I recognize I am accepting risk. What I am avoiding is the surprise of a ^version-compatible file introducing new and unwanted “features”.
- pabs3 5y agoWhat do you do for security updates? There are a lot of them for NPM modules. Seems GitHub manages the database for those now: https://github.com/advisories https://github.com/advisories
- ficklepickle 5y agoI swear 99% of them are prototype pollution or regex DOS that don't apply to how I'm using the dependency.
- CodeWriter23 5y agoSnapshot VM, npm install
- pabs3 5y agoAnd how do you know that is safe and hasn't exfiltrated all your data or used a VM escape exploit.
- 0des 5y ago
- gorjusborg 5y agoNope, just a smaller circle of trust.
- oauea 5y agoVet and pin your dependencies.
- TobyTheDog123 5y agoUntil something bundled with a large amount of linux distros has a root privilege escalation[1]. [1] https://access.redhat.com/security/vulnerabilities/RHSB-2022-001 https://access.redhat.com/security/vulnerabilities/RHSB-2022...
- deleted 5y ago[deleted]
- djbusby 5y agoAren't bugs different than malice? I sure hope so or I'm in a tight spot.
- TobyTheDog123 5y agoMy main point was that it's silly to treat stdlibs as gospel and everything else as vulnerable nonsense.
- gorjusborg 5y agoYes. I checked out a small project recently and it had over 2000 nom packages as dependencies. The culture around node development was/is just too dependency happy. I get standing on the shoulders of giants and that not all people are bad, but with thousands of dependencies, the chances of a supply chain issue starts to become significant.
- tomjen3 5y agoMost people are good, but because destruction is so much easier than creation a few people can destroy what it takes a lot of people to build. For example it will take Ukraine months just to dig the bodies out the destroyed family homes that Russia spend a few minutes bombing. However I don't think the number of dependencies is a useful number: node was one of the first languages to have a build in standard way to get and manage dependencies, which meant that dependencies could be much, much smaller. Boost for C++ is a giant project, so you can say that your C++ project only has a few dependencies, but if C++ had a decent standard dependency manager, projects like Boost were probably split up more. * I am aware Maven exists for Java, but the cultural expectations for Java were set long before it became a thing.
- deleted 5y ago[deleted]
- fshbbdssbbgdd 5y agoSeems like overkill. You can just pin the version of the dependency and host it, no? It’s standard practice the last few places I’ve worked.
- 0des 5y agoUnless you are reviewing their code too then it is no different. I've read every privacy policy and TOS I've ever signed and even I can't fathom reviewing node modules to completion. I don't even know if that is possible given that any node project can have endless cyclic dependencies
- fshbbdssbbgdd 5y agoI have worked at a big famous tech company where you had to have approval for every dependency. It was slow to get a new library reviewed, but usually the popular ones were already on the list. I think this process actually scales reasonably well because the more engineers you have, the more likely it is someone else has been there before.