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

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

271–280 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#271

Post by jmull »

Someone1234 wrote: post #34
jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

> That's an INSANE default.

I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement.

The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time.

IMO, the hyperbole here hurts because it distracts from more effective efforts.

Re: Malicious npm packages detected across Red Hat Cloud Services

#272

Post by tmpz22 »

insanitybit wrote: post #135

Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…

> anything where code executes

ALL the agentic orchestrators like codex, claude-code, etc. seem to do this by default.

Re: Malicious npm packages detected across Red Hat Cloud Services

#273

Post by bananamogul »

nailer wrote: post #102
jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

You didn't include Perl's CPAN, which I think is older (1995) than all of these. And it allows scripts as well.

Re: Malicious npm packages detected across Red Hat Cloud Services

#274

Post by czbond »

rochak wrote: post #149

If this is what will take for folks to move away from JS ecosystem, I'll take it.

I am not a JS dev, but had to interact with the ecosystem some. It became so bad I won't install anything without it being in a Docker or Podman container.

Re: Malicious npm packages detected across Red Hat Cloud Services

#275

Post by jruohonen »

matheusmoreira wrote: post #99
gbear605 wrote: post #66

Earlier quoted context omitted.

One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and point…

> where it can be reviewed > Critically, there must be time for someone to review By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here. Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have…

Indeed, my sentiment also, which I posted elsewhere:

https://news.ycombinator.com/item?id=48358080

Re: Malicious npm packages detected across Red Hat Cloud Services

#276

Post by sysguest »

homebrewer wrote: post #154
johannes1234321 wrote: post #107

Earlier quoted context omitted.

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing sma…

This has been improving recently; one large project built on several heavy libraries that I've been supporting since 2018 currently installs ~180 dependencies without loss of functionality compared to how it worked, and what it depended on, back in 2018. IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself: - 5 deps: https://www.npmjs.com/package/react/v/…

hmm maybe time to get into deno?

I mean, the current "allow ANY filesys operation" can't cope with modern supply-chain attacks...

with deno, you can specify folders/files that the execuble/library CAN touch (or CANNOT)

Re: Malicious npm packages detected across Red Hat Cloud Services

#277

Post by xena »

jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Ask and you shall receive: https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-c...

Re: Malicious npm packages detected across Red Hat Cloud Services

#278

Post by icedchai »

bandrami wrote: post #125
ImPostingOnHN wrote: post #74

Earlier quoted context omitted.

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as. It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed…

That's why we don't let the developers run system package manager install scripts as root. We do let them run npm inside containers, which is still more access than I'd like them to have.

Is this one of those places where it takes 6 to 12 weeks to get something new installed on your machine?

Re: Malicious npm packages detected across Red Hat Cloud Services

#280

Post by Sankozi »

matheusmoreira wrote: post #144
Someone1234 wrote: post #34

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

> allows all packages to run package supplied arbitrary code as the logged-in user after an update completes As opposed to the completely untrusted package supplied arbitrary code that the logged in user executes when they actually use the package immediately after installing it?

One malicious script that is run right after install vs one per each API entry point that might be called or not (transitive dependency).
Post reply on HN