Live data from Hacker News

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

bleepingcomputer.com

721–730 of 1001 posts

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

#721

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

> at this point I just see him as holding other committers contributions as hostage

No he's not, and you're just trying to be outraged. Just fork the code if you don't trust him. Oh, but you don't want to take his place as the maintainer? Maybe deep down you know that there's still a difference between being in charge and submitting the occasional pull request?

Your actions contradict your words here.

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

#722

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…

Security auditor here.

Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations.

Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mirrors JS many companies import ;)

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

#723

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…

You don't have to always pull the latest release on utility packages if you want to evade such problems. Sure, you would need to audit a lot of packages in certain languages...

But yes, I prefer to "vendor" my dependencies too, especially on large projects.

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

#724
post #168

Earlier quoted context omitted.

The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging systems. And even then you need a way to source exactly that version without relying on the original author's cooperation. Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a wh…

Then the package manager should be changed to make it more convenient.

There is no way around the issue because "dependency hell" is indeed a thing.

Dependencies change. Dependencies of dependencies change. You can't not update any of your dependencies for too long or there will be other problems. Something is gotta give.

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

#725
post #60

Earlier quoted context omitted.

Quoted post unavailable.

You've run afoul of https://en.wikipedia.org/wiki/Poe%27s_law

The tone changes half way, it wasn't all parody, though :-)

Thought it would be clear enough.

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

#726

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…

[deleted]

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

#727

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…

I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?

I think it's more because dependencies are generally used less because all the tooling around it is much worse than in other languages.

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

#728

Earlier quoted context omitted.

I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.

I also like doing this, but with node, you have a massive tree of thousands of files. It's crazy and gross.

Yarn 2 pnp kinda fixes this

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

#729

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…

You don't have to always pull the latest release on utility packages if you want to evade such problems. Sure, you would need to audit a lot of packages in certain languages... But yes, I prefer to "vendor" my dependencies too, especially on large projects.

Security vulns are fixed daily in most webapp dependency trees.

If you do not update you are vulnerable to piles of issues anyone can look up.

If you update blindly you may import new obvious supply chain attacks.

The solution is actually doing code review. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. The extra effort to use a minimal framework and some cherry picked functions may be worth it for most orgs.

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

#730
post #726

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…

[deleted]

[deleted]
Post reply on HN