Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

131–140 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#133
post #69

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…

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. In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't hand…

How large a project do you typically use dotnet for?

IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.

Re: Malicious npm packages detected across Red Hat Cloud Services

#134
post #27
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_...

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

> It's frequently repeated here just cause of the average bias against Node.

It’s frequently repeated here because NPM is where it keeps happening over and over and over and over and over and over again.

Re: Malicious npm packages detected across Red Hat Cloud Services

#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 test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.

3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.

(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.

There are some vendors in this space that you can and should evaluate as well.

Re: Malicious npm packages detected across Red Hat Cloud Services

#136

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

That might change the odds, but unless you fork diligently (and monkeypatch each and every future vulnerability) you might ship a compromised fork forever.

Re: Malicious npm packages detected across Red Hat Cloud Services

#138

The joke is on you NPM! I only use CDNs for my JS libraries.

Same. I came back to do a little frontend work a couple of years ago and was horrified by the replacement of script tags with subresource integrity with npm and bundlers.

Re: Malicious npm packages detected across Red Hat Cloud Services

#139
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_...

All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.

It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.
Post reply on HN