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

691–700 of 1001 posts

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

#691

Post by gitgrump »

0xbadcafebee wrote: post #297

The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects). We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software developme…

No. JavaScript developers (and Go developers) live in the "wild, wild west". Those of us using system package repositories with proper maintainers have been doing just fine for years, thanks.

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

#692

Post by staticassertion »

xg15 wrote: post #667
staticassertion wrote: post #420

Earlier quoted context omitted.

> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is ju…

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 could reach them, and as such it could constrain the program's capabilities accordingly.

In fact, compilers already do this for control flow integrity - it would just be a more advanced system.

> What happened if an update requests a new permission?

It's going to depend on the system. For browser extensions the new permission means a new prompt, so you'd get a CI failure until a human updated a lockfile.

> Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.

It really depends on the system. You could have a CPU capability that restricts cycles or forces preemption, etc.

I'm not saying you can solve literally all security problems but you can reduce risk considerably. If "infinite loop" is the scariest thing a dependency can do we're in a pretty good position. An unconditional infinite loop should break your CI tests.

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

#693

Post by glenneroo »

sli wrote: post #284

I'll admit that I cracked up pretty good over this, and am glad that I'm not working in JS/TS every day anymore for reasons among these kinds, but I am firmly on the developer's side on this one. Github suspending the developer's account is well within the realm of the type of questionable actions I expected out of Github after its acquisition by MS and only makes me feel even better about my long-ago move to Gitlab…

Sorry to repeat this again (too many repeated threads) but he was already temp-banned from GH around 2013 (i.e. before the Microsoft acquisition) for "creating a script that forced people to watch a library that [he] created", whatever that means: https://youtu.be/varf6oWaFtU?t=202

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

#694

Post by lenkite »

I see the license is still the MIT license. Why doesn't this narcissist dev change the license to say: "Companies who do not pay me $1 million shall NOT consume this" ?

Why is he still using an open for all consumption license and then complaining that billion dollar companies are leeching him? (After hosting his library on said billion dollar company)

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

#695

Post by lenkite »

obviousanswer9 wrote: post #642
balls187 wrote: post #625

Earlier quoted context omitted.

> I think Marak is teaching an important and principled lesson here. What lesson is that?

Quoted post unavailable.

The author should first change his LICENSE before he does crap like this. Make sure the terms of the license upfront state that "billion/trillion dollar companies" are not permitted to use this library. Stop using the MIT license for your hactivist project.

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

#697

Post by Beldin »

ratorx wrote: post #221
pc86 wrote: post #179

Earlier quoted context omitted.

Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific ver…

The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…

> I agree that it’s ultimately the developers fault for allowing code to be automatically injected

Let's not do victim blaming here.

This is ultimately the fault of the person deliberately updating their package to break other people's software.

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

#698

Post by balls187 »

obviousanswer9 wrote: post #642
balls187 wrote: post #625

Earlier quoted context omitted.

> I think Marak is teaching an important and principled lesson here. What lesson is that?

Quoted post unavailable.

Most of what you wrote has merit, but I dont believe the author was trying to impart much of what you wrote. I let my comments inline with yours.

> a) blindly 'updating' and deploying code without testing is a horrible idea

This is important risk factor each organization should be aware of. Though he wasn't trying to convey this, it was merely a byproduct.

> b) these trillion dollar corporations just take and take and never give, and boy do they whine and cry when the devs don't 'hold up their end of the deal' and keep turning out perfect, fully tested software for free

This was the intent, but anecdotally, Google, Amazon, Apple, Microsoft, Twitter, Meta, Stripe, Netflix, all contribute to open source.

> c) 'the source is open so anyone can look at it and therefore it's bug free' is and always has been a mentally retarded philosophy

Since the source is open, it must be bug free is a flawed conclusion. Again, not the lesson Marak was imparting.

> d) the software deployment process as it's currently practiced is horribly flawed

I don't think that is accurate.

> e) these people ought to count their blessings that the code is flawed in such an obvious and immediately detectable rather than subtle and devious and much more destructive way

I can't imagine a more destructive way that would result in the catastrophe one is expecting. Should Marak have been more malicious, having a myriad of well funded corporations targeting him would not be fun.

and last but not least:

> f) giving control over one's code to evil microsoft via github is an incredibly stupid idea, as such authority WILL be abused by the evil scumbags.

Another tradeoff organizations should understand.

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

#699

Post by dhruvrrp »

epaulson wrote: post #167

It's time for someone to make a Redhat, but for "safe" open source software libraries. My big enterprise would sign up for it in a heartbeat. We'd pay for access from an alternative NPM registry where everything is at least semi-vetted - someone at least looks at diffs before new versions get updated and made available. Sure, the "safe" repo wouldn't have as nearly as many packages as the main NPM repo, but if it had…

The usecase I’ve seen similar to this has been Artifactory. If a dev wants to use a package, then a specific version gets pulled and hosted in the internal Artifactory repository and then all build tools use it to pull packages.

The way I’ve seen (and might not be the best way) people handle ownership is if a dev wants to use lets say ‘colors’ from npm, then they/their team takes ownership of that package internally. I guess an issue would arise if the big co is doing development on a public repo, so they’re forced to use npm/dockerhub/etc.

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

#700

Post by lenkite »

syshum wrote: post #257
stjohnswarts wrote: post #207

Earlier quoted context omitted.

It still doesn't mean you can't call the guy out for being an asshole. However, that's the only relief you'll get in matters such as these. Other avenues would be to tweet about it and make it known that this is what you can expect from the same guy in the future so avoid him for future work as he won't be acting like an adult.

That also does not mean you cant call out the corporations that are leaching off open source... I find it ironic that people are more upset at this guy for complaining about corporations, than they are about the corporations leaching... the dev and hacker communities have really gone full on #HailCorporate haven't they. Where did my anti-establishment Libre community of the 90's go... I long for the good old days

He is leeching off a "corpo" by hosting his library on a "corpo" site.
Post reply on HN