I think these kinds of attack would be strongly reduced if js had a strong standard library. If it was provided, it would significantly trim dependency trees of all the small utility libraries. Perhaps we need a common community effort to create a “distro” of curated and safe dependencies one can install safely, by analyzing the most popular packages and checking what’s common and small enough to be worth being inclu…
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
661–670 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#662Earlier quoted context omitted.
Sign the package with hard keys and signature. That's really the core issue. Developer-signed packages (npm's current attack model is "Eve doing a man-in-the-middle attack between npm and you," which is not exactly the most common threat here) and a transparent key registry should be minimal kit for any package manager, even though all, or at least practically all, the ecosystems are bereft of that. Hardening API sur…
How are users supposed to build and maintain a trust store? In a hypothetical scenario where npm supports signed packages, let's say the user is in the middle of installing the latest signed left-pad. Suddenly, npm prints a warning that says the identity used to sign the package is not in the user's local database of trusted identities. What exactly is the user supposed to do in response to this warning?
This is a solved problem.
https://en.wikipedia.org/wiki/Web_of_trust
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#663This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…
For python I use Debian packages wherever possible. What I need is in there usually. I might even say almost always.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#664Earlier quoted context omitted.
I've been arguing a couple of times that the 2 main reasons people want package management in languages are 1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package. So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though th…
Nope. It's because: 1. You don't want to tie your software to the OS. Most people want their software to be cross-platform. Much better to have a language-specific package manager because I'm using the same language on every OS. And when I say "OS" here, I really mean OS or Linux distro , because Linux doesn't have one package manager. 2. OS package managers (where they even exist), have too high a bar of entry. Not…
I actually agree in the context of user software people often want the latest and that Windows and OS don't have proper package management is an issue.
However we are talking in the context of NPM packages which by the vast majority would be running inside a container on some server. So how could that software not use a stable Debian base for example.
And arguing that package management is to complicated is a bit ridiculous considering how many workloads are running in docker containers which I'd argue are significantly more complex
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#665For those of you without a security dept, hopefully this is of some help: https://github.com/Cobenian/shai-hulud-detect
more updates soon and PRs welcome.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#666Earlier quoted context omitted.
Requiring you to audit both security and robustness on the LLM generated code. Creating two problems, where there was one.
I didn't say generate :) - in all seriousness, I think you could reasonably have it copy the code for e.g. lodash.merge() and paste it into your codebase without the headaches you're describing. IMO, this method would be practical for a majority of npm deps in prod code. There are some I'd want to rely on the lib (and its maintenance over time), but also... a sort function is a sort function.
LLMs don't copy and paste. They ingest and generate. The output will always be a generated something.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#667Earlier quoted context omitted.
> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…
If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.
is it that infeasible with LLMs?
a lor of these dependencies are higher order function definitions, which never change, and could be copy/pasted around just fine. they're never gonna change
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#668Earlier quoted context omitted.
The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself . Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.
And then when node is updated and natively supports set intersections you would go back to your copied code and fix it?
If it works, why do so? Unless there's a clear performance boost, and if so you already know the code and can quickly locate your interpreted version.
Or At the time of adding you can add a NOTE or FIXME comment stating where you copied it from. A quick grep for such keyword can give you a nice overview of nice to have stuff. You can also add a ticket with all the details if you're using a project management tool and resuscitate it when that hypothetical moment happens.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#669Wow it got everything, aws keys, gcp keys, github tokens, thats a lot of cryptocoin mining instances that are going to be spun up. And a lot of unexpected bills people are going to be getting...
They really shouldn't have been stored unencrypted on peoples machines.... Ouch.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#670Earlier quoted context omitted.
Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.
Just the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies). https://github.com/tursodatabase/turso/network/dependencies
Yeah. You have dev dependencies in there, those alone will increase number of dependencies by ~500, without ending up in the final product.
Those numbers are way off their actual number.