Live data from Hacker News

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

741–750 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#741

Earlier quoted context omitted.

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…

> This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day. By default npm will create a lock file and give you the exact same version every time unless you manually initiate an upgrade. Additionally you could even remove the package-lock.json and do a new npm install and it still wouldn't upgrade the package if it already exists in you…

Ahh this might explain the behavior I observed when running npm install from a freshly checked out project where it basically ignored the lock file. If I recall in that situation the solution was to run an npm clean install or npm ci and then it would use the lock file.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#742

I was just reading an article in Foreign Affairs that was discussing a possible future with an increased separation of science and technological developments between China and The West. And it occurred to me, what would such a siloed landscape mean for OSS and basically the whole web infrastructure as it is today, shared and open for anyone in any country. I think this kind of malware becoming pervasive could be the…

May I ask which article it was? The Once and Future China?

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#743

It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes. Ed…

I think that depends on...how are these malicious changes actually getting into these packages? It seems very mysterious to me. I wonder why npm isn't being very forthcoming about this?

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#744

I was just reading an article in Foreign Affairs that was discussing a possible future with an increased separation of science and technological developments between China and The West. And it occurred to me, what would such a siloed landscape mean for OSS and basically the whole web infrastructure as it is today, shared and open for anyone in any country. I think this kind of malware becoming pervasive could be the…

May I ask which article it was? The Once and Future China?

Thats the one

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#745
For years everyone in the programming community has been pushing for convenience and features and code reuse and its got to the point I think the ease of adding a third party package from the languages package manager or github needs to be seriously questioned by security conscious devs. Perhaps we made the wrong things easy.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#746
post #339

Earlier quoted context omitted.

As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like

How does that relate to the bigger conversation here? Are you suggesting people stop pulling Go packages from GitHub and only use local dependencies?

I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager

That said, I would guess the 'bigger conversation' is that it is much harder to tpyo > than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend)

None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#747

Earlier quoted context omitted.

I found it funny back when people were abandoning Java for JavaScript thinking that was better somehow...(especially in terms of security) NPM is good for building your own stack but it's a bad idea (usually) to download the Internet. No dep system is 100% safe (including AI, generating new security vulns yay). I'd like to think that we'll all stop grabbing code we don't understand and thrusting it into places we don…

It’s not clear to me what this has to do with Java vs JavaScript (unless you’re referring to the lack of a JS standard library which I think will pretty much minimize this issue). In fact, when we did have Java in the browser it was loaded with security issues primarily because of the much greater complexity of the Java language.

It's not the language it's the library that's not designed to isolate untrusted code from the start. Much harder to exit the sandbox if your only I/O mechanism is the DOM, alert() and prompt().

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#748
post #476
post #280

Earlier quoted context omitted.

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I've also seen something similar with Java, with its culture of "pure Java" code which reimplements everything in Java instead of calling into preexisting native libraries. What's common between Java and Go is that they don't play well with native code; they really want to have full control of the process, which is m…

I think it's important for managed/safe languages to have their own implementations of things, and avoid dropping down into C/C++ code unless absolutely necessary. ~13 years ago I needed to do DTLS (TLS-over-UDP) from a Java backend, something that would be exposed to the public internet. There were exactly zero Java DTLS implementations at the time, so I chose to write JNI bindings to OpenSSL. I was very unhappy wit…

[deleted]

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#749
post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

>It's not feasible for me to audit every single one of my dependencies Perhaps I’m just ignorant of web development, but why not? We do so with our desktop software.

Average .net core desktop complex app may have a dozen dependencies if it get to that point. Average npm todo list may have several thousand if not more

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#750

Earlier quoted context omitted.

The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package

The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately. There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

What kind of code does this developer write?

Post reply on HN