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

561–570 of 797 posts

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

#561

Post by cyphar »

ghurtado wrote: post #494
nine_k wrote: post #434

Earlier quoted context omitted.

Semver was invented to facilitate that. Only if everyone adhered to it.

> Semver was invented to facilitate that First time I've heard that. How does semver facilitate backporting?

Of course it doesn't provide backports by itself, it's a versioning system. But version number changes with SemVer are meant to indicate whether an update includes new fearhews or not (minor bump means new features, patch bump means bugfixes only).

Of course, the actual issue is that maintaining backports isn't free, so expecting it from random single-person projects is a little unrealistic. Bug fixes in new code often need to be rewritten to work on old code. I do maintain old release branches for some projects and backporting single patches can cause whole new bugs that were never present in the main branch quite easily.

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

#562

Post by jwpapi »

nathan_compton wrote: post #426

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

You could still leak API keys

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

#563

Post by hinkley »

twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that).

It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes that much work just to see daylight.

The last time I chimed in on this I hypothesized that there must have been a change in management on the npm team but someone countered that several of the maintainers were the originals. So I’m not sure what sort of Come to Jesus they had to realize their giant pile of sins needed some redemption but they’re trying. There’s just too much stupid there to make it easy.

I’m pretty sure it still cannot detect premature EOF during the file transfer. It keeps the incomplete file in the cache where the sha hash fails until you wipe your entire cache. Which means people with shit internet connections and large projects basically waste hours several times a week doing updates that fail.

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

#564

Post by strbean »

LeifCarrotson wrote: post #454
christophilus wrote: post #436

Earlier quoted context omitted.

What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?

I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates. I don't run much on the root OS of my dev machine, basically everything is in a container…

You could create/run thin proxies for every external service that handle the auth side, and run each in a separate container. Orchestrate everything with docker-compose. Need to connect to cloud services for local development? Have a container with a proxy that transparently handles authentication. Now only that container has the secrets for talking to that service.

That's a lot of work though, and increases the difference between your local dev environment and prod.

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

#565

Post by cyphar »

devttyeu wrote: post #236
gnfargbl wrote: post #95

Earlier quoted context omitted.

I'm a huge Go proponent but I don't know if I can see much about Go's module system which would really prevent supply-chain attacks in practice. The Go maintainers point [1] at the strong dependency pinning approach, the sumdb system and the module proxy as mitigations, and yes, those are good. However, I can't see what those features do to defend against an attack vector that we have certainly seen elsewhere: projec…

In Go you know exactly what code you’re building thanks to gosum, and it’s much easier to audit changed code after upgrading - just create vendor dirs before and after updating packages and diff them; send to AI for basic screening if the diff is >100k loc and/or review manually. My projects are massive codebases with 1000s of deps and >200MB stripped binaries of literally just code, and this is perfectly feasible. (…

You absolutely can, both systems are practically identical in this respect.

> In Go you know exactly what code you’re building thanks to gosum

Cargo.lock

> just create vendor dirs before and after updating packages and diff them [...] I don’t believe I can do the same with Rust.

cargo vendor

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

#566

Post by hinkley »

timgl wrote: post #460
smallerfish wrote: post #455

Because PostHog's "Talk to a human" chat instead gets a grumpy gatekeeping robot (which also doesn't know how to get you to a working urgent support link), and there's nothing prominently on their home page or github about this: Hey PostHog! What version do we need to avoid?

co-founder here. We mentioned it in the main thread about this: https://news.ycombinator.com/item?id=46032650 and on status.posthog.com - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 If you make sure you're on the latest version you should be good.

This is now the main thread. Though dang likes to merge dupes.

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

#567

Post by Sparkle-san »

plomme wrote: post #346
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.

Because AppSec requires us to adhere to strict vulnerability SLA guidelines and that's further reinforced by similar demands from our customers.

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

#568

Post by smt88 »

leo_e wrote: post #508

Postman getting hit is scary. For many teams, it's effectively an unmanaged password manager for API keys.

No one should have sensitive/production keys in Postman. That's a huge security lapse in the first place.

My devs don't have access to production keys at all (and would never need them).

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

#569

Post by madeofpalk »

twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

You shouldn't have any keys anywhere at all. Use OIDC https://docs.npmjs.com/trusted-publishers

Unfortunately you need to `npm login` with username and password in order to publish the very first version of a package to set up OIDC.

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

#570

Post by madeofpalk »

halflife wrote: post #552
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

What does it do with packages that download binaries for specific architecture in the post script?

You don't need post-install scripts for this. Use optionalDependencies instead https://github.com/nrwl/nx/blob/master/packages/nx/package.j...

Each of those deps contains a constraint installing only for the relevant platform.

Post reply on HN