Also package manager should not run scripts.
Shai-Hulud Returns: Over 300 NPM Packages Infected
191–200 of 797 posts
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#192Earlier quoted context omitted.
The packages were published using a compromised key directly, not through our ci/cd. We rolled the key, and published a new clean version from our repo through our CI/CD: https://github.com/PostHog/posthog-js/actions/runs/196303581...
Why do you keep using token auth? This is unacceptable negligence these days. NPM supports GitHub workflow OIDC and you can make that required, disabling all token access.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#193> Upon execution, the malware downloads and runs TruffleHog to scan the local machine, stealing sensitive information such as NPM Tokens, AWS/GCP/Azure credentials, and environment variables. That's a wake up call to harden your operations. NPM Tokens, AWS/GCP/Azure credentials have no reason to be available in environments where packages may be installed. The same goes for sensitive environment variables.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#194Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
But realistically, I think the sum total of compromises via package managers attacks is much smaller than the sum total of compromises caused by people rolling their own libraries in C and C++.
It's hard to separate from C/C++'s lack of memory safety, which causes a lot of attacks, but the fact that code reuse is harder is a real source of vulnerabilities.
Maybe if you're Firefox/Chromium, and you have a huge team and invest massive efforts to be safe, you're better off with the low-dependency model. But for the median project? Rolling your own is much more dangerous than NPM/Cargo.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#195"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
Okay then, tell me a way to prevent this.
https://bootstrappable.org/ https://reproducible-builds.org/ https://github.com/crev-dev
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#196Earlier quoted context omitted.
There are ecosystems that have package managers but also well developed first party packages. In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.
2020 State of the Octoverse security report showed that .NET ecosystem has on average the lowest number of transitive dependencies. Big part of that is the breadth and depth of the BCL, standard libraries, and first party libraries.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#197Earlier quoted context omitted.
There's nothing technically different between NPM and, say, Cargo, here that would save Cargo, is there?
This is a cultural problem created through a fundamental misunderstanding (and mis-application) of Unix philosophy. As far as I'm aware the Rust ecosystem doesn't have a problem appropriately sizing packages which in turn reduces the overall attack surface of dependencies.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#198Earlier quoted context omitted.
I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the si…
C standard library is also very small. The issue is not the standard library. The issue is adding libraries for snippets of code, and in the name of convenience, let those libraries run code on the dev machine.
Doing dev in a VM can help, but isn’t totally foolproof.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#199"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
Okay then, tell me a way to prevent this.
This does not prevent said package from shipping with malware built in, but it does prevent arbitrary shell execution on install and therefore automated worm-like propagation.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#200I guess you should never use the latest versions of libraries.
Not sure if you're serious, but if so I agree that people should take the time to set up their own package mirrors. Not just for npm but all other package managers as well. This is why it's so important to get to know what you're actually building instead of just "vibing" all the time. Before all the AI slop of this decade we just called it being responsible.
The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues will continue.
Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection at least, checking what dependencies they also use, their code and tests quality, etc.
Package managers should enforce namespacing for ALL packages, should improve their publishing security, and should probably have an opt-in verified program for the most important packages.
Doing these will go a long way to ameliorate these supply chain attacks