For those unfamiliar with the context: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
the onion article is still up could link that
'No way to prevent this,' says only package manager where this regularly happens
101–110 of 230 posts
Re: 'No way to prevent this,' says only package manager where this regularly happens
#102I think people are overlooking the fact that the javascript ecosystem is run by perpetual beginners who are probably using 5 different SAAS credential managers and still manage to check their creds into a public git repo. No wonder there are so many breaches. Rust developers otoh are typically experts and don't get pwned so easily.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#103I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…
Seems like you dropped something: > Disclaimer: I maintain depsguard
Yikes. You are correct. Honest truth, I got a few downvotes (after a few more upvotes), thought this was the cause, but you’re right. Didn’t think that it matters much, I’ll add it back. Had no idea anyone noticed. Fair enough, thanks for keeping me honest.
Edit: added it back, inline.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#104Earlier quoted context omitted.
> It seems like it might just be that Python/npm are juicier targets? Attackers go where the victims are. Frontend is a monoculture with the vast majority using NPM; backend, less so. This isn't an excuse for NPM, but another strike against it. You could also argue that the attacks make a deeper point about frontend vs backend devs, but I won't go there.
Why would you even imply something like that?
[flagged]
Re: 'No way to prevent this,' says only package manager where this regularly happens
#105What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages
"What are the actual guarantees that make that don't make?"
Re: 'No way to prevent this,' says only package manager where this regularly happens
#106I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…
This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#107Ah yes, only `npm` has ever suffered an attack. Ever.
RubyGems: https://www.sonatype.com/blog/anatomy-of-the-rubygems-rest-c... PyPi: literally the latest attack included publishing malicious packages on PyPi XZ Tools, a part of nearly every Linux distribution nearly merged in code to backdoor SSH: https://www.akamai.com/blog/security-research/critical-linux...
It is just easy pickings to blame npm specifically. Yes, while they do share some part of the blame, no package manager is immune from attack and certainly not ones where the attackers exploited being able to extract out secrets from a developer's environment variables or files. Seems more like developers should be managing their secrets better?
I also find that using the meme that this title snowclones is in bad taste too.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#108Earlier quoted context omitted.
This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.
There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privil…
> There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package)
You don't need to test a compromised package to have it execute code. Importing it anywhere in your tests is enough, even transitively.
It's for sure less likely to run but I doubt it's significantly different in practice.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#109What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages
Generally, other package managers aren't great either. Notably, crates.io / cargo has some of the same issues as NPM and the verbiage of their excuses for not fixing these problems is oddly similar. Something fascinating about the design and architecture of programming languages and their surrounding ecosystems is the enormous leverage that they provide to the "core team": For every 1 core language developer[1]... ..…
You appear to have missed that NPM is owned by Microsoft.
In addition, crates.io has not flatly refused to support namespaces, there's an entire accepted RFC for it: https://github.com/rust-lang/rfcs/pull/3243
At the same time, note that namespacing does nothing to prevent any sort of problem here. Namespacing is great for package organization and making provenance more deliberately obvious, but beyond that it's not a security measure.
Re: 'No way to prevent this,' says only package manager where this regularly happens
#110What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages
Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but i…
> Part of the point the article makes is that most other popular languages have a comprehensive standard library.
Both the Browser and Node.js standard library are fairly extensive. I don't think there's much you can do with other language you can't do with Node.js. And as a lot of newer languages have demonstrated (like zig and hare), you don't need an extensive one.