Live data from Hacker News

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

bleepingcomputer.com

31–40 of 1001 posts

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

#31
post #10
post #4

Earlier quoted context omitted.

GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.

Why would the developer of any software that comes explicitly without warranty be hold responsible for downstream breakages? It's not as if one could force people to upgrade to newer versions and they can always keep depending on the old releases.

The warranty issue is a red herring. A warranty is an affirmative guarantee of quality: you are (in essential concept of not in precise detail) agreeing to be held to a "strict liability" standard. If I buy real estate and I am granted a warranty deed, and the title to the property comes into question, the seller can be brought to account to make me whole or indemnify me, regardless of who is at fault for the title defect.

Without a warranty, you're not held to strict liability, but you can probably be held liable under the default legal regime. If I buy real estate and get a quit-claim deed, there is no promise that the seller has unencumbered rights to the property. However, if I can show the seller intentionally defrauded me, they can still be held civilly and criminally liable for the fraud.

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

#32

What exactly does colors do?

> What exactly does colors do?

A picture is worth a thousand words → https://i.imgur.com/inxA7Pg.png

The library inserts ANSI escape sequences [1] between the text you want to colorize in order to, well, colorize it ¯\_(ツ)_/¯

Many people are obsessed with colors in the Terminal, and so, they reach out to libraries like this. They exist in every major programming language ecosystem, even though colorizing text is as simple as writing this \x1b[48;5;011\x1[0m . One of the disadvantages of this rudimentary colorization technique is that if you have short-term memory, you will quickly forget the meaning of these numbers, but you can solve that problem with constants, there is no reason to install a third-party library with potentially malicious code to add this type of functionality to a high-profile project like AWS-CDK [2].

I wish these libraries would support NO_COLOR [3] more consistently.

I have seen many “modern” CLI tools (the ones people like to build using Rust or Go) overuse colors with no option to disable them.

[1] https://stackoverflow.com/a/33206814

[2] https://github.com/aws/aws-cdk/pull/18324/files

[3] https://no-color.org

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

#33

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 don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.

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.

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

#34
Obviously he has this right to do what he wants and he did. But the consequences are that his reputation is in tatters. Probably doesn't bother him but equally the repos will be forked and utilization continues of the predecessor. Might not be a maintainer mind you so the dependent repos will quickly find alternates.

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

#35

Earlier quoted context omitted.

> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.

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.

In practical terms, can they really be audited?

This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.

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

#36
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 particular issue all goes back to Snyk, as seen in the bottom of the blog post. Seems like they are labeling this a DoS to justify being able to publish something in their database and blog.

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

#37

Earlier quoted context omitted.

> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.

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, but I wouldn't use any that are developed by a rando with no reputation or "institutional oversight." An important part of choosing to use one is evaluating the maintainers.

Does the JavaScript ecosystem have anything like Apache Commons? I'm guessing not, but it probably should.

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

#39

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…

Introducing a deliberate endless loop is not like changing the API of a library, no.
Post reply on HN