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

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

561–570 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#561

Post by arp242 »

Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

You're overestimating the amount of auditing these distros do for the average package; in reality there is very little.

The reason these compromised packages typically don't make it in to e.g. Debian is because this all tends to be discovered quite quickly, before the package maintainer has a chance to update it.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#563

Post by [deleted] »

johnisgood wrote: post #213
juliend2 wrote: post #195

Earlier quoted context omitted.

> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…

C encourages such culture, too, FWIW.

[deleted]

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#564

Post by johtso »

kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#565

Post by touristtam »

brw wrote: post #558
foxfired wrote: post #554

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more. I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know whic…

Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.

That and pin that damn version!

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#566

Post by rpcope1 »

Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

Yeah, after seeing all of the crazy stuff that has been occurring around supply chain attacks, and realizing that latest Debian stable (despite the memes) already has a lot of decent relatively up-to-date packages for Python, it's often easier to default to just building against what Debian provides.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#567

Post by raxxorraxor »

spankalee wrote: post #377
pixl97 wrote: post #240

Earlier quoted context omitted.

I mean, what does do good if your supply chain is attacked? This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it. Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.

The supply chain infrastructure needs to stop being naive and allowing for insecure publishing. - npm should require 2FA disallow tokens for publishing. This is an option, but it should be a requirement. - npm should require using a trusted publisher and provenance for package with over 100k downloads a week and their dependencies. - Github should require a 2FA step for automated publishing - npm should add a cool do…

The reality is that for a huge crowd of developers 2FA doesn't do shit.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#568

Post by cookiengineer »

Icathian wrote: post #302
juliend2 wrote: post #195

Earlier quoted context omitted.

> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…

Go sits at about the same level of abstraction as Python or Java, just with less OO baked in. I'm not sure where go's reputation as "low-level" comes from. I'd be curious to hear why that's the category you think of it in?

I'd argue that Go is somewhere in between static C and memory safe VM languages, because the compiler always tries to "monomorphize" everything as much as possible.

Generic methods are somewhat an antipattern to how the language was designed from the start. That is kind of the reason they're not there yet, because Go maintainers don't want boxing in their runtime, and also don't want compile time expansions (or JIT compilation for that matter).

So I'd argue that this way of handling compilation is more low level than other VM based languages where almost everything is JITed now.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#570

Post by jay_kyburz »

_puk wrote: post #544
jay_kyburz wrote: post #535

Earlier quoted context omitted.

Yes, fewer, larger, trustworthy dependencies with tree shaking is the way to go if you ask me.

Almost like a standard library..

Yeah, but perhaps we could have different flavors. If you like functional style you could have a very functional standard library that doesn't mutate anything, or if you like object oriented stuff you could have classes of object with methods that mutate themselves. And the Typescript folks could have a strongly typed library.
Post reply on HN