Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

341–350 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#341

Post by mschuster91 »

skydhash wrote: post #178
mschuster91 wrote: post #138

Earlier quoted context omitted.

> That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. Yeah, that's why I said that this is the other end of the pendulum. > In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. Oh I'm aware of that. My point still stands - that comes at a serious maintenance cost…

Wait what? That’s just fearmongering, how hard is it to add a few methods that split a string or pad it? It’s not rocket science.

> how hard is it to add a few methods that split a string or pad it?

Well, if you're in C/C++, you always risk dealing with null pointers, buffer overruns, or you end up with use-after-free issues. Particularly everything working with strings is nasty and error-prone if one does not take care of proper testing - which many "homegrown" libraries don't.

And that's before taking the subtleties of character set encodings between platforms into account. Or locale. Or any other of the myriad ways that C/C++ and even Java offer you to shoot yourself in the foot with a shotgun.

And no, hoping for the best and saying "my users won't ever use Unicode" or similar falls apart on the first person copying something from Outlook into a multi-line paste box. Or someone typing in their non-Latin name. Oh, and right-to-left languages, don't forget about these. What does "pad from left" even mean there? Is the intent of the user still "at the beginning of the string itself?" Or does the user rather want "pad at the beginning of the word/sentence", which in turn means padding at the end of the string?

There's so much stuff that can go horribly horribly wrong when dealing with strings, and I've seen more than my fair share just reading e-mail templates from supposed "enterprise" software.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#342

Post by afdbcreid »

wongarsu wrote: post #254
galangalalgol wrote: post #227

Earlier quoted context omitted.

Network without async works fine in std. However, rand, serde, and num_traits always seem to be present. Not sure why clap isn't std at this point.

Clap went through some major redesigns with the 4.0 release just three years ago. That wouldn't have been possible if clap 2.0 or 3.0 had been added to the stdlib. It's almost a poster child for things where libraries where being outside the stdlib allows interface improvements (date/time handling would be the other obvious example). Rand has the issue of platform support for securely seeding a secure rng, and having…

FWIW, there is an accepted proposal (https://github.com/rust-lang/libs-team/issues/394) to add random number generation to std, and adding traits like in `num-traits` is wanted, but blocked on inherent traits.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#343

Post by falcor84 »

jacquesm wrote: post #54
darkamaul wrote: post #26

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.

I don't think that this Kantian argument is relevant in tech. We've had LTS versions of software for decades and it's not like every single person in the industry is just waiting for code to hit LTS before trying it. There are a lot of people and (mostly smaller) companies who pride themselves on being close to the "bleeding edge", where they're participating more fully in discovering issues and steering the direction.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#345

Post by vorticalbox »

christophilus wrote: post #239
vorticalbox wrote: post #218

Earlier quoted context omitted.

the issue is not that devs don't know what they are its that they don't pin packages if you run `npm i ramda` it will set this to "ramda": "^0.32.0" (as of comment) that ^ means install any version that is a feature or patch. so when a package is released with malware they bump version 0.32.1 and everyone just installs it on next npm i. pinning your deps "ramda": "0.32.0" completely removes the risk assuming the vers…

> the trade off I see that as a desirable feature. I don’t want new functionality suddenly popping into my codebase without one of my team intending it.

me too but a lot of people see it as massive overhead they don't want to deal with.

personally i pin all mine because if you don't a version could be deployed during a pipeline and this makes your local version not the same as the one in docker etc.

pinning versions is the only way to be sure that the version I am running is the same as everyone elses

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#346

Post by plomme »

darkamaul wrote: post #26

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#347

Post by exceptione »

skeeter2020 wrote: post #271
pasc1878 wrote: post #247

Earlier quoted context omitted.

Or purchase third party libraries. This does two things - limits what you drag in and also if you drag it in you can sue someone for errors.

This definitely not why enterprise "chooses" C# and neither of these were design decisions like implied. MS would have loved to have the explosive, viral ecosystem of Node earlier in .NET's life. Regardless a lot of companies using C# still use node-based solutions on the web so a insular development environment for one tier doesn't protect them.

I am not so sure about that. .net core is the moment they opened up, making it cross platform, going against the grain of owning it as a platform.

If they see a gap in .net, which is filled in by a third party, they would have no problem qualms about implementing their own solution in .net that meets their quality requirements. And to be fair, .net delivers on that. This might anger some, but the philosophy is that it should be a batteries included one-stop shop, maybe driven by the culture of quite some ms shops that wouldn't eat anything unless ms feeds it them.

This has a consequence that the third-party ecosystem is a lot smaller, but I doubt MS regrets that. If you compare that to F#, things are quite different wrt filling in the gaps, as MS does not focus on F#. A lot of good stuff for F# comes from the community.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#348

Post by afdbcreid »

TheFlyingFish wrote: post #316
gorgoiler wrote: post #232

Earlier quoted context omitted.

And yet of course the world and their spouse import requests to fetch a URL and view the body of the response. It would be lovely if Python shipped with even more things built in. I’d like cryptography , tabulate/rich , and some more featureful datetime bells and whistles a la arrow . And of course the reason why requests is so popular is that it does actually have a few more things and ergonomic improvements over th…

Requests is a great example of my point, actually. Creating a brand-new Python venv and running `uv add requests` tells me that a total of 5 packages were added. By contrast, creating a new Rust project and running `cargo add reqwest` (which is morally equivalent to Python's `requests`) results in adding 160 packages, literally 30x as many. I don't think languages should try to include _everything_ in their stdlib, a…

That's not an apple-to-apple comparison, since Rust is a low-level language, and also because `reqwest` builds on top of `tokio`, an async runtime, and `hyper`, which is also a HTTP server, not just a HTTP client. If you check `ureq`, a synchronous HTTP client, it only adds 43 packages. Still more, but much less.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#349

Post by WD-42 »

wongarsu wrote: post #100
TheFlyingFish wrote: post #70

Earlier 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…

I wouldn't call the Rust stdlib "small". "Limited" I could agree with. On the topics it does cover, Rust's stdlib offers a lot . At least on the same level as Python, at times surpassing it. But because the stdlib isn't versioned it stays away from everything that isn't considered "settled", especially in matters where the best interface isn't clear yet. So no http library, no date handling, no helpers for writing ma…

Rand, uuid, and no built in logging implementation are three examples that require crates but probably shouldn’t.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#350

Post by merelysounds »

tasuki wrote: post #334
merelysounds wrote: post #34

Earlier quoted context omitted.

There is an explanation in the article: > it modifies package.json based on the current environment's npm configuration, injects [malicious] setup_bun.js and bun_environment.js, repacks the component, and executes npm publish using stolen tokens, thereby achieving worm-like propagation. This is the second time an attack like this happens, others may be familiar with this context already and share fewer details and ex…

I don't get this explanation. How does it force you to run the infection code? Yes, if you depend on an infected package, sure. But then I'd expect not just a list, but a graph outlining which package infected which other package. Overall I don't understand this at all.

Look at the diff in the article, it shows the “inject” part: the malicious file is added to the “preinstall” attribute in the package.json.
Post reply on HN