NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
Malicious npm packages detected across Red Hat Cloud Services
191–200 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#192[dead]
Re: Malicious npm packages detected across Red Hat Cloud Services
#193I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
Re: Malicious npm packages detected across Red Hat Cloud Services
#194Earlier 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…
I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version. This makes it so an update to a popular library can compromise a huge number of packages that depend on it. In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.
MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.
Re: Malicious npm packages detected across Red Hat Cloud Services
#195Earlier quoted context omitted.
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.
The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
Pip, Composer, RubyGems, NuGet, and several others have lifecycle scripts.
As of course do the OS managers -- apt, yum, Homebrew.
Re: Malicious npm packages detected across Red Hat Cloud Services
#196Earlier quoted context omitted.
The problem would be the dependencies of your dependencies, and keep going many levels.
But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation. That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.
Would Red Hat be considered a trusted/reputable vendor? :-D
Re: Malicious npm packages detected across Red Hat Cloud Services
#197[dead]
Re: Malicious npm packages detected across Red Hat Cloud Services
#198Earlier quoted context omitted.
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.
IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
That changes nothing. If you're downloading packages pushed by randoms, then it's vulnerable. There is no escaping it. Go's module index is filled with people's GitHub repositories. You have no idea what's inside those things unless you review the source yourself.
Re: Malicious npm packages detected across Red Hat Cloud Services
#199Earlier quoted context omitted.
> 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?
The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.
Sure but like.. come on. Is that really a defense? Most packages are run on devs machines. And it's not like "Oh it's just running on my production server, what could go wrong there" is any better.
Re: Malicious npm packages detected across Red Hat Cloud Services
#200Earlier 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
Most of them? Ruby gems have hooks, Python has setup.py, deb, rpm have them too (relevant if you're installing from 3rd party sources). Elixir/Mix doesn't technically execute code on install, but your language server builds the dependencies as soon as you open the project, which can execute arbitrary code.
Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.