Earlier quoted context omitted.
> 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. This is semi-common and in no way unique to NPM.
What other package managers do this? I don’t think Ruby does
Malicious npm packages detected across Red Hat Cloud Services
151–160 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#152Earlier quoted context omitted.
> That's an INSANE default. It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?
There are so, so many things that NPM could do. It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them. It could add an optional key to package.json that allows someone to whitelist which packages can run insta…
You realize that "dependency cooldowns" as a popular concept are extremely new, right? npm manages the installation of dependencies for millions upon millions of users across the globe.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
Re: Malicious npm packages detected across Red Hat Cloud Services
#153Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
pnpm also support this
Re: Malicious npm packages detected across Red Hat Cloud Services
#154Earlier 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. 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…
> 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/15.6.2
- 0 deps: https://www.npmjs.com/package/react/v/19.2.6
Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.
Re: Malicious npm packages detected across Red Hat Cloud Services
#155Earlier quoted context omitted.
Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny. How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?
It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
[flagged]
Re: Malicious npm packages detected across Red Hat Cloud Services
#156I 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.
Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.
Re: Malicious npm packages detected across Red Hat Cloud Services
#157Earlier 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…
> 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. This is semi-common and in no way unique to NPM.
You're right. I said the same thing and got downvoted too. Don't let it discourage you.
Re: Malicious npm packages detected across Red Hat Cloud Services
#158This seems to be sinister
Re: Malicious npm packages detected across Red Hat Cloud Services
#159Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
`pnpm` also has that and it's on by default since `v11`: https://pnpm.io/settings#minimumreleaseage
It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate.
Re: Malicious npm packages detected across Red Hat Cloud Services
#160Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
pnpm also support this
The gist link above covers how to use it in yarn, npm, and pnpm