391–400 of 1001 posts
Earlier quoted context omitted.
Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.
Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.
This vulnerability was reported to NPM in 2016: https://blog.npmjs.org/post/141702881055/package-install-scr... https://www.kb.cert.org/vuls/id/319816 but the NPM response was WAI.
Acronym expansion for those-not-in-the-know (such as me before a web search): WAI might mean "working as intented", or possibly "why?"
This seems like something that can be solved with reproducible builds and ensuring you only deploy from a CI system that verifies along the way. In fact this blog post appears to be advertising for a system that secures build pipelines. Google has written up some about their internal approach here: https://cloud.google.com/docs/security/binary-authorization-...
Earlier quoted context omitted.
Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, pro…
I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.
Earlier quoted context omitted.
> in JS land almost everyone uses lax dependency declarations They do, BUT. Dependency versioning schemes are much more strictly adhered to within JS land than in other ecosystems. PyPi is a mishmash of PEP 440, SemVer, some packages incorrectly using one in the format of the other, & none of the 3 necessarily adhering to the standard they've chosen. Other ecosystems are even worse. Also - some ecosystems (PyPi again…
The point is still different. In PyPI, if I put `requests` in my requirements.txt, and I run `pip install -r requirements.txt` every time I do `make build`, I will still only get one version of requests - the latest available the first time I installed it. This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day. And the ecosystem being…
I'm going to assume this is you running this locally to generate releases, presumably for personal projects?
If you're building your projects in CI you're not pulling in the same version without a lockfile in place.
Earlier quoted context omitted.
Maybe the language should have a standard library then.
C library is smaller than Node.js (you won’t have HTTP). What C have is much more respectable libraries. If you add libcurl or freetype to your project, it won’t pull the whole jungle with them.
But does yarn or deno suffer from the same issues? That is do they get their packages from npm repositories? I've never used these.
Earlier quoted context omitted.
Can't help noticing, in the original article: > The entire attack design assumes Linux or macOS execution environments, checking for os.platform() === 'linux' || 'darwin'. It deliberately skips Windows systems If I were the conspiracy-minded sort I might jump to some wild conclusions here.
I’m using windows again. By default windows has “power shell” which is not at all like bash and is (how do I say this diplomatically)… wanting. I mean it says something the developed the Linux Subsystem for Windows, but it’s an optional install.
So don’t expect PowerShell to be like a UNIX shell. It isn’t, and wasn’t meant to be one. It’s different, on purpose :)
Earlier quoted context omitted.
Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, pro…
Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.