Live data from Hacker News

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

bleepingcomputer.com

61–70 of 1001 posts

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

#61

My sense is that it’s time to evolve licensing such that wealthy major consumers of packages that have become somewhat essential are naturally paying a licence fee. The problem is not in what the code does it’s a problem with the agreement for use.

> My sense is that it’s time to evolve licensing such that wealthy major consumers of packages that have become somewhat essential are naturally paying a licence fee.

Yes, it's called paid software, but don't worry, it's going to be trendy again soon.

The days of free software contribution are almost over.

Devs want to be paid for their work. too many corporations made billions from open source projects while maintainers live in quasi poverty.

What is needed is a proper market place for paid open source software. Github isn't one.

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

#62
post #47

This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.

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

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

#63
post #60
post #43

Earlier quoted context omitted.

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

Quoted post unavailable.

npm also has immutable artifacts.

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

#64

Doesn't it seem strange that Snyk is creating a vulnerability report for this + labeling it a DoS? DoS is something someone executes against a target, in this case a package had it's functionality (purposefully) altered. That's like calling changing the API of a popular library DoS, because now application authors need to change their code/use a different library... Fittingly enough, all four solutions for this parti…

> Doesn't it seem strange that Snyk is creating a vulnerability report for this + labeling it a DoS?

I think it most definitely falls into "malicious code" that certainly is not done in good faith, and if not handled properly by downstream users, can cause a lot of unexpected problematic failures.

Whatever labels are used to characterize this, whether to call it a vulnerability/DoS or not, are just a matter of arguing over semantic meaning.

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

#65
post #43

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…

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

How does that solve the issue here of new broken versions of packages being published?

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

#66

Earlier quoted context omitted.

Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.

> Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time. It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers." I use packages…

Not just that they've fully embraced the "written by randos" but even worse: "as soon as the rando publishes an update or change, use it!" They seem to fully automate updates because packages are so poorly written (and frankly, it probably helps with revenue stream, if their client's websites occasionally break and need them to fix it.)

...and meanwhile NPM's idea of vetting packages is basically "YOLO, BRO!"

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

#67
For a bit more context: https://news.ycombinator.com/item?id=29839786

In essence, It seems to be the case of a developer getting screwed, being disillusioned, becoming political, making bombs?, attacking the ecosystem etc.

Many years ago, I recall another developer of popular NPM packages(Azer Koçulu) pulling a similar thing[0].

https://qz.com/646467/how-one-programmer-broke-the-internet-...

We followed each other on Twitter, I recall him being disillusioned with SV and angry to Wikipedia for some reason(I think he believed on some greater plan or agenda pushed by SV companies, including Wikipedia). I disagreed and got unfollowed and blocked. Later, if I recall correctly, he got married and was touring the world.

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

#68

Doesn't it seem strange that Snyk is creating a vulnerability report for this + labeling it a DoS? DoS is something someone executes against a target, in this case a package had it's functionality (purposefully) altered. That's like calling changing the API of a popular library DoS, because now application authors need to change their code/use a different library... Fittingly enough, all four solutions for this parti…

I guess most customers of snyk if not all, are going to be happy that they tagged this as a vulnerability. I'm not sure why they would have done anything differently, seems like exactly why they are paid for (I don't use them and have no relationship with them)

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

#69
post #22

Earlier quoted context omitted.

In this case, the developer's behavior was malicious: they intentionally caused damage. This is very different than some good faith change that breaks stuff downstream. Sure, the license says "no warranty". But github can decide that they won't tolerate vandals on their platform. It would be within their right to revert the bad change from the git database they hold, go back to the last good change and lock the devel…

What damage did they cause?

Do you really expect anyone to believe that you're asking that in good faith?
Post reply on HN