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

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

Post reply on HN
Print view View original

991–1000 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#991

Post by CRConrad »

shukantpal wrote: post #222
gokhan wrote: post #169

Earlier quoted context omitted.

It's not the original gift that is the problem, all maintainers start very happy early on but keeping software up while adding more features is costly, someone needs to pay an it's almost always paid by the maintainer in terms of free time. If you intend to keep it as the original gift, it will be called abandoned.

> keeping software up while adding more features is costly The software maintenance is also given out as a gift. That's a choice.

> The software maintenance is also given out as a gift. That's a choice.

So he's perfectly entitled to choose not to do that any more, no?

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#992

Post by CRConrad »

spijdar wrote: post #394
no_wizard wrote: post #374

This isn’t a vulnerability nor is it corrupt, these are intentional actions on behalf of the project maintainer. Not that I agree per se, to be absolutely clear, however saying these are corrupt or somehow vulnerabilities isn’t the truth. This is the software working as intended

They are absolutely corrupt -- intentionally corrupt, but the intention was to break the software in retaliation. Drilling holes in your boat to sink it means yes, it is sinking "as intended", but it's still an act of sabotage. I suppose you can specifically argue against the word corrupt as implying a corruption of the author's intention, but I think it also applies to "does not behave as anticipated". (now, the int…

> Drilling holes in your boat to sink it means yes, it is sinking "as intended", but it's still an act of sabotage.

No, it's scuttling. "Sabotage" is when you do it to other people's stuff.

It was his code, so it can't have been sabotage.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#993

Post by collinmanderson »

pas wrote: post #405
hsbauauvhabzb wrote: post #361

Earlier quoted context omitted.

Does updating it with junk take any longer?

dependabot (GitHub's free? notifier) is probably the biggest risk factor in npm supply-chain attacks. Because who audits the actual diffs? "npm-crev" can't come soon enough... https://web.crev.dev/rust-reviews/ https://github.com/crev-dev/cargo-crev

Interesting. Do those reviews apply to packages as a whole, or different versions of a specific package? Edit: Yes, the reviews can apply to specific versions.

I'm personally a fan of using Debian/Ubuntu packages, because generally code goes through a human before it gets published. That human has already been trusted by the Debian or Ubuntu organization.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#994

Post by collinmanderson »

Beldin wrote: post #697
ratorx wrote: post #221

Earlier quoted context omitted.

The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…

> I agree that it’s ultimately the developers fault for allowing code to be automatically injected Let's not do victim blaming here. This is ultimately the fault of the person deliberately updating their package to break other people's software.

> This is ultimately the fault of the person deliberately updating their package to break other people's software.

Ultimately the 2017 Equifax data breach was the fault of the people who hacked into Equifax's website.

We need systems in place to defend against people doing malicious things, but yes ideally individual developers shouldn't be the ones tasked with reviewing all of their dependencies' code.

Operating System provided packages, for example, are generally reviewed by someone other than the author, which can lead to a more secure supply chain.

Rust's cargo-crev review system also seems like a possible solution the problem.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#995

Post by CRConrad »

ajkjk wrote: post #17
scotty79 wrote: post #16

So people learned basically nothing from leftPad.js ?

What were they supposed to learn? "Don't have dependencies"?

> What were they supposed to learn? "Don't have dependencies"?

Yes.

Or vet them thoroughly.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#996

Post by CRConrad »

sydthrowaway wrote: post #379

Honestly, the whole bomb making stuff was out of left field. This guy is Mr Robot

Sounds much more like fireworks to me: All those powdered metals burn in pretty colours. Also feels supported by the fact that the charges were dropped.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#997

Post by daudmalik06 »

notRobot wrote: post #21

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

Totally agree with you, i think it's time to think carefully and immediately start using services like Vulert(https://bit.ly/336DZub) that tracks your open-source softwares for free and notifies you in real-time if any seccurity issue is found within your applciation. it's free.

atleast in this way we can secure ourselves from supply chain attacks

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#998

Post by dudeinjapan »

saltminer wrote: post #912
tjpnz wrote: post #549

Earlier quoted context omitted.

Where do you draw the line? I've learned the hard way that SemVer isn't universally respected in the Node ecosystem. What happens if the maintainer of a sufficiently popular package decides to push out a patch release overhauling the public facing API? Does Github ban them too?

I'm reminded of Mongoid, which was at one point using SemVer, but stopped, and at least one company was caught off guard by breaking changes in (seemingly) minor releases ( https://news.ycombinator.com/item?id=29845724 ).

Am working with Mongoid team to get them to use semver again. There is hope yet.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#999

Post by pas »

collinmanderson wrote: post #993
pas wrote: post #405

Earlier quoted context omitted.

dependabot (GitHub's free? notifier) is probably the biggest risk factor in npm supply-chain attacks. Because who audits the actual diffs? "npm-crev" can't come soon enough... https://web.crev.dev/rust-reviews/ https://github.com/crev-dev/cargo-crev

Interesting. Do those reviews apply to packages as a whole, or different versions of a specific package? Edit: Yes, the reviews can apply to specific versions. I'm personally a fan of using Debian/Ubuntu packages, because generally code goes through a human before it gets published. That human has already been trusted by the Debian or Ubuntu organization.

This aims to explicitly solve the problem of "okay, but most maintainers just skim the code at best and spend time on packaging", plus it aims to parallelize it.

And while some packages have been distroized (eg. a lot of old perl packages, a lot of python packages, some java/node packages) I have no idea if any rust package is distro packaged separately. (Since rust is static linked there's no real reason to package source code. Maybe as source package. But crates.io is already immutable.)

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#1000

Post by IYasha »

daveevad wrote: post #381
notRobot wrote: post #21

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

the whole point of the internet > are literally remote code exec vulns

I applaud you ) HTML-based WEB1.0 was so much safer and faster...
Post reply on HN