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

91–100 of 1001 posts

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

#91

Post by infogulch »

heluser wrote: post #43
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…

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

Immutability feels like the best approach here. Go's module system is pretty good in this respect: "proxy" is just a proxy that serves module code, and "sum" is an append-only transparency log of the hashes of all published versions. You can't "unpublish" from the log, but you can get code hosted on proxy removed for various reasons... which users can protect themselves against by running their own proxy. Go's module version resolution strategy means that the chosen module version never changes without explicit input from the user so no "publish a new version that breaks everyone's CI" issue.

All together I don't see how GP's "email php files around" is as any better than this system in any way.

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

#92

Post by wbl »

mjlawson wrote: post #58
heluser wrote: post #43

Earlier quoted context omitted.

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

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.

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

#93

Post by commandlinefan »

ruuda wrote: 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.

> pin all dependencies

You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.

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

#94

Post by thefourthchime »

Osmose wrote: post #74

It's a bit wild that the sum total money spent on salaries for engineers handling potential problems stemming from this or defending against the possibility in the future could probably have covered paying the maintainer a living wage many times over.

Living wage? haha, more like 100 peoples living wage.

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

#95

Post by tailspin2019 »

evolve2k wrote: post #30
evolve2k wrote: post #26

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.

Actually in attempting to answer my own question, on other platforms like YouTube and Medium, popular content receives monetary support by virtue of being popular. What if this was addressed at the “platform” level, I’m thinking the package manager here, NPM. If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”. I’d pe…

> If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”.

This seems like a pretty decent idea…

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

#96

Post by hnthrowaway0315 »

Maybe everyone should include a clause in the license to force commercial use to pay certain "tribute" e.g. 0.01% of gross revenue.

Worst case everyone is going to invent their own wheels, which is beneficiary to all lower-echelon programmers (but not so for managers/tech leads as they have responsibility to ship things) because I as one definitely want to invent as many wheels as possible.

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

#97

Post by drawkbox »

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…

Dependencies are a major attack vector now.

Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war.

Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to worse than DLL hell, telemetry tracking/data, and attack vectors that can take down or target many, many systems.

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

#98

Post by notatoad »

commandlinefan wrote: post #85

> now what stop trying to save a couple of bucks by reusing functionality that's not that hard to just develop in-house maybe?

only helps if people developing the functionality that is difficult to develop in-house do the same. i'm not going to build my own AWS cdk.

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

#99

Post by cerved »

rich_sasha wrote: post #35
notRobot wrote: post #33

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.

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.

look at diffs?

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

#100

Post by maxwell86 »

mjlawson wrote: post #58
heluser wrote: post #43

Earlier quoted context omitted.

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

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

THat's why you specify the exact version of your dependencies.
Post reply on HN