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

961–970 of 1001 posts

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

#961

Post by jamaicahest »

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 worked with several banks as a devops consultant and have helped implement self-hosted proxy repositories for NPM, NuGet, etc. These proxies save a copy of every package downloaded and store it locally for as long as the bank wants. Developers are then blocked from downloading from any other repository than these proxies. This solves the problem of packages being taken offline, but it does very little against malicious code on new versions of the package. However it also provides the ability to reproduce code X years into the past, as can be required of banks by financial regulators in various countries.

As always it is a cost/benefit trade-off: what is the benefit to auditing every package vs. the cost of auditing every package?

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

#962

Post by emteycz »

krona wrote: post #933
kodemager wrote: post #777

Earlier quoted context omitted.

But the ownership of the apples doesn’t automatically change hands just because their owner decides to poison them.

Forfeiture is the loss of any property without compensation as a result of defaulting on contractual obligations, or as a penalty for illegal conduct.

Where is the court judgement for that?

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

#963

Post by gertrunde »

My own opinion on this:

A developer updating their code & packages in whatever way they see fit is their right. Those folk downstream consuming these packages are responsible for policing their supply chain with regard to security/quality/risk.

That being said, this is a significantly anti-social move that will (quite rightly) negatively impact their reputation, and the trust placed in them, their code, and the packages derived from their code.

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

#964

Post by meekmind »

tluyben2 wrote: post #957
heurisko wrote: post #815

Earlier quoted context omitted.

> Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihoo…

> The person who unthinkingly installs a package will also unthinkingly include your script using 'require' The npm stories show that most people do this with npm though. This color thing shows many people will just install whatever without checking: manually or automatically. The advantage of this php require thing is that it takes effort to do and the author makes sure it is not 100000+ files (npm routinely install…

Passing around PHP files via email is functionally equivalent to passing out mix-tapes on street corners. Not a good tactic when a record label right around the corner will give you world-wide distribution for free. The only string attached is you'll have to rely on others of which you know very little, if anything.

I do not recommend being consistent with that position in other areas of your life otherwise you might quickly find yourself in a jungle, starving and naked. Given that relying on others for shelter, food, or clothing is clearly out of the question!

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

#965

Post by Sharparam »

knute wrote: post #835
Aeolun wrote: post #827

Earlier quoted context omitted.

> I believe you should be guarded from any surprise patches As far as I know, NPM install still thinks it’s a feature that they install new (compatible with package.json, but not with lockfile) versions.

Which is why you only use `npm install` for development, and `npm ci` for production.

No, updating versions should require an explicit `update` command of some sort. The NPM commands should really just be renamed:

- `npm install` should be renamed to `npm upgrade`

- `npm ci` should be renamed to `npm install`

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

#966

Post by ryanbrunner »

heurisko wrote: post #762
notRobot wrote: post #758

Earlier quoted context omitted.

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

> 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. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…

At the very least, distributing in this way (presumably with some license clause that it can't be later placed in a package repository) prevents other libraries using this library as a dependency. Expecting developers to review what's happening with libraries is mostly unrealistic, but expecting them to review changes in the dependencies of the libraries you use is completely hopeless.

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

#967

Post by ryanbrunner »

heurisko wrote: post #839
newaccount74 wrote: post #821

Earlier quoted context omitted.

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code. You can even experiment with the packages directly, by editing the files in vendor/.

With node_modules, the amount of required code becomes unmanageable to review very, very quickly (sometimes with the installation of a single package).

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

#968

Post by ryanbrunner »

brundolf wrote: post #470
pinum wrote: post #426

Earlier quoted context omitted.

>You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }

I mean... that's true if you ever use any code that you haven't read through line-by-line. That's not specific to package managers in general, much less NPM, so I think it's out of scope for this discussion.

Not really. I can be reasonably sure that end-user applications I download for a desktop are limited in the damage they can do (even more so for iOS or Android). This isn't something that happens often with programming libraries, but there's no inherent reason they can't be built in a way that they run in a rights-limited environment.

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

#969

Post by Siira »

rezonant wrote: post #954
dcow wrote: post #952

Earlier quoted context omitted.

The GLP affects the entire work. If some fancy pants proprietary shop got caught publishing a release that incorporated an AGPL `faker` then a GPL request would render all the source code. This would be a legal nightmare for some places. Have you heard what happens when an acquirer finds a GPL bomb during due diligence?

I'm very familiar with the GPL, I just meant folks would rather find non-GPL alternatives. For a library that wraps a few ANSI terminal codes to enable color and provides a bunch of fake data for testing, I think finding alternatives (or just writing them yourself) wouldn't be hard.

I guess the OP means that it would be too late to replace the AGPL code if the company has already published a version including it. My unexpert opinion agrees with the OP.

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

#970

Post by CRConrad »

Sohcahtoa82 wrote: post #871
detaro wrote: post #826

Earlier quoted context omitted.

How does a maintenance contract make the software not-FLOSS? It's a working option if you need more promises than the license gives you.

The F in FLOSS is supposed to stand for Free. Many people interpret it as "Free as in beer", not "Free as in speech", so expecting people to pay for it disqualifies it as FLOSS.

> Many people interpret it as "Free as in beer", not "Free as in speech", so expecting people to pay for it disqualifies it as FLOSS.

Only for people with the wrong expectations. Just because there's many of them doesn't make them right.

Post reply on HN