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

261–270 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#261

Post by tonymet »

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

Npm developers can relate to Windows being a target because it’s the most popular package manager.

Why would you target xyz pkg niche manager knowing that only 200 people will install them?

NPM does perform active offline & online vuln scanning on the packages. Everyone can do more, but they are going to be the #1 target.

Re: Malicious npm packages detected across Red Hat Cloud Services

#262

Post by tonymet »

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…

So does dpkg & rpm

Re: Malicious npm packages detected across Red Hat Cloud Services

#264

Post by tremon »

rixed wrote: post #204
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…

One hour ago, while looking casually at a package.json, I saw this and was horrified: rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory tha…

To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.

Re: Malicious npm packages detected across Red Hat Cloud Services

#265

Post by tln »

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…

Maybe NPM is scared to break a ton of packages? I also think action from NPM on the repo level is vital

I went through the package.json on my machine - seems like ~400 / 60000 or 0.7% have (pre|post)install. (That's not all of the scripts that run at install)

Seems to me like a backwards compatibility is a non argument since pnpm is popular enough to stand as existence proof that scripts can be, at least, opt-in

IMO - pre- and post- install scripts should just be abolished/deprecated. It should require a special dispensation from npm to even publish one. A better system for binaries (needed by esbuild) is probably needed.

Even saying "just use pnpm" isn't enough, we need to get the developer community to herd immunity and that isn't going to happen on an opt-in basis.

I would love for npm to sandbox as well. But I think the better way forward is just turn off scripts.

Re: Malicious npm packages detected across Red Hat Cloud Services

#266

Post by [deleted] »

marcosdumay wrote: post #235
paulddraper wrote: post #203

Earlier quoted context omitted.

The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.

Hum... You should check your JavaScript numbers again. I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).

[deleted]

Re: Malicious npm packages detected across Red Hat Cloud Services

#267

Post by user3939382 »

vinnymac wrote: post #159
mihaelm wrote: post #147

Earlier quoted context omitted.

`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. https://github.com/yarnpkg/berry/pull/7135

If this were a universal default, would the strategy defeat itself?

Re: Malicious npm packages detected across Red Hat Cloud Services

#268

Post by pajko »

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…

So do the pre- and post-install scripts of Debian packages. The problem is not this but the lack of verified and controlled release channel.

Re: Malicious npm packages detected across Red Hat Cloud Services

#269

Post by nailer »

isityettime wrote: post #227
m4rtink wrote: post #143

Earlier quoted context omitted.

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets…

Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that. The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of…

> Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it.

Not all packages come from the distro. People can and do enable external sources for software that isn't part of their OS.

Re: Malicious npm packages detected across Red Hat Cloud Services

#270

Post by winrid »

kylebebak wrote: post #207
dmix wrote: post #5

Our 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...

npm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`

not if you have internal repos?
Post reply on HN