Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps • Hacker News Board

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

#751

Post by kaba0 » Mon, Jan 10, 2022, 9:53 AM UTC

oblio wrote: post #82

tablespoon wrote: post #37

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

It's both technical and cultural. Javascript is used on the front end. Front end devs obsess (or at least used to obsess) over download sized. So you'd have crazy stuff like custom builds of Underscore ( https://underscorejs.org/ ) with just the functions you wanted. Think manual sandboxing, if that makes any sense. You could get a package of Underscore with just map, filter and reduceRight, if you wanted to. Now, wh…

I really don’t think it is fair to blame it on Java. Having very little native dependency is a huge plus to an ecosystem (just look at what Java will be able to do with Loom thanks to the almost all-Java dependencies). Also, Java was particularly keen on downloading class files at runtime, so linking everything was not even possible.

And it is not even a difficult thing to fix without going the linker way: java’s modules essentially solve it (as well as javascript modules could/can) — just specify what is visible outside a package and both ecosystems can “tree-shake” non-used code (though I dislike this nonstandard term)

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

#752

Post by godDLL » Mon, Jan 10, 2022, 9:57 AM UTC

heartbreak wrote: post #546

godDLL wrote: post #510

Earlier quoted context omitted.

"Abused Github to distribute malicious code" is a legal wording, not a EULA violation. A lawsuit, not an account ban. Let's decide how serious this is. Exactly. I am, for one, of the opinion that it is not at all serious. Not deserving of a lawsuit or an account ban. Not even newsworthy. I mean, this could easily become the new normal for OSS. You use it – you're not insured against anything, for there is no formal c…

You don’t need a contract to be protected against intentional harm.

In a society. Hence, "social contract".

There is no Zuckerverse contract.

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

#753

Post by heurisko » Mon, Jan 10, 2022, 9:57 AM UTC

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…

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages.

This offers no benefit in terms of security, over a package dependency locked at a specific version.

The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead of curl.

It doesn't contribute to security at all, it just makes it awkward for other people to use your code.

I would also assume that people are connecting your library to a package management system anyway, to overcome this unnecessary hurdle e.g. https://getcomposer.org/doc/05-repositories.md#loading-a-pac...

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

#754

Post by michaelt » Mon, Jan 10, 2022, 10:01 AM UTC

staticassertion wrote: post #692

xg15 wrote: post #667

Earlier quoted context omitted.

Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner. What happened if an update requests a new permissio…

> Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that c…

> In theory a compiler knows every reachable system call and all points of data input that could reach them

Sorta yes, sorta no.

Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too.

Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices".

Sandboxing PC software is tough.

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

#755

Post by helsinkiandrew » Mon, Jan 10, 2022, 10:01 AM UTC

jopsen wrote: post #750

lrvick wrote: post #722

Earlier quoted context omitted.

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 mi…

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

If projects are importing tens or hundreds of third party libs without any kind of validation or review the process is fatally flawed.

Whatever the language or repository system reusing libraries like React, Requests, Apache commons, or lodash make sense after reviewing the pros and cons (functionality, security, size, performance etc). But blindly adding small repositories to your packages file without understanding the implications is only increasing the risk of trouble.

Node and npm for some reason seems to have encouraged this - remember leftpad.

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

#756

Post by Bolkan » Mon, Jan 10, 2022, 10:04 AM UTC

heurisko wrote: post #753

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…

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead…

By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.

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

#757

Post by heurisko » Mon, Jan 10, 2022, 10:07 AM UTC

Bolkan wrote: post #756

heurisko wrote: post #753

Earlier quoted context omitted.

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead…

By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.

Composer (PHP dependency manager) does not force you into doing automatic upgrades.

You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.

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

#758

Post by notRobot » Mon, Jan 10, 2022, 10:11 AM UTC

heurisko wrote: post #753

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…

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead…

I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people.

To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended.

The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code.

There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.

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

#759

Post by foxfluff » Mon, Jan 10, 2022, 10:13 AM UTC

shaunpersad wrote: post #121

AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…

> But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such.

I support freedom of speech too; I explicitly allow you (or anyone) to be an asshole, but if everyone is an asshole all the time, I might pick up my toys and leave.

That's right, I prefer a world where people are nice and do nice things voluntarily and out of respect / compassion / desire to suppport / etc. instead of doing things a certain way because a law or contract requires it.

And so is largely my stance on free software (and more.. music, games, etc.). I would not expect most people to pay or donate, and it would be impossible to write a license that requires it without discriminating against those who can't or just don't find it worthwhile. Free software works best when it comes with no strings attached.

However, if something I made got really popular and thousands of companies started relying on it, I'd expect to see at least some support. And if everyone just kept taking but never showed any support, it's quite possible I'd get burned out on it, especially if popularity also came with a lot of demands and entitlement. And if everyone felt entitled to just take and never give, I would also feel totally entitled to replace my own project with "thanks for all the fish" when I'm done with it.

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

#760

Post by realityking » Mon, Jan 10, 2022, 10:20 AM UTC

TranquilMarmot wrote: post #397

seattle_spring wrote: post #345

Earlier quoted context omitted.

You should always commit a lockfile (either npm's or yarn.lock) alongside package.json

This helps with CI and deploys, but on developer machines running `npm i` will install different things at different times. The amount of churn a `package-lock.json` file undergoes when all of the dependencies have a `^` is crazy.

When you have a package-lock.json file npm i will not upgrade packages. You have to do that manually.

The biggest churn in package-lock.json files is from using different npm versions. It’s worth keeping them aligned within a dev team.