by author Fernando Doglio
This is not the first time something like this happens, but I wouldn't blame NPM for this. I wouldn't even blame the Nod...
For further actions, you may consider blocking this person and/or reporting abuse
But this is not our fault.π
NPM is like wanting a banana and getting a jungle. It was stated in this post that vetting our dependencies is the only way.
If one brings 20 and 20 of those have 200 and those have 2000 dependencies well I'm not sure how many years I would need to check several files with potential for n hundred lines.
But then the only solution is automated checking as npm does (quite poorly depending who you ask), that is where we are right now. Automated checks are unfortunately retroactive, there has to be some victims the ensure the safety of the rest of us. Proactive human checking will always win as long as it's not a large job, I just don't think the pace of sprints tie nicely with this timeline.
It kinda is I'm afraid, yeah npm should have some responsability, but in the end it's up to us to understand how it works, and take messures to securize our applications as much as posible. But we can't do much apart from the solution presented in this post. Although that has it's drawbacks too, minor/patch version sometimes contain security fixes that would not be installed until we do it manually. We would need to be quite responsible and update our dependencies manually each couple of days to get access to those fixes. But we also would need to check what the updates are and check for insecure code... which in my opinion it's not posible (or at least not easy) for smaller teams.
So yeah, I guess we're screwed, damn...
Do your best I suppose it's all we can do. I know in truth it is down to us all to be sucure - thank you for the post Keff :)
Isnβt it what a
package-lock.json
andnpm ci
do ?From the node.js documentation
Can I blame society or capitalism?
What if behind every npm package there is a team of well payed developers working really hard to mantain the code? That would be nice.
Also, everyone should add
ignore-scripts=true
to their.npmrc
. It will stopnpm
from running pre-install or post-install scripts.Hmm, true, but in the same time there is growing number of known vulnerabilities in packages which developers already use. That's why there are services like dependabot, which are constantly updating project deps. So what's the better option? To update or not to update? When you are updating, you are opening your project to those attacks, but when you are not updating, hackers may just find known vulnerabilities in your dependencies and exploit them.
It's not about locking your deps and then forgetting about them, instead it should be about locking them for every prod deploy, meaning that if you want to update them, you have to go through the same testing/uat/prod cycle, to ensure that whatever gets into prod actually works.
Because after all, it's true, you do want those other updates, but can you blindly trust them?
I just don't see how humans can check all fo this, its not possible in the timescale of a human lifetime. Id rather pay sombody to write an AI to do it for a fraction of the cost
Start to tame Deno
Okay. Society, capitalism and communism. Is that better?
Yarn