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

761–770 of 1001 posts

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

#761

Post by DarkWiiPlayer »

bruce511 wrote: post #558
franciscop wrote: post #267

Earlier quoted context omitted.

I have a different opinion, but I respect yours; and that's the basis of open source. There's many, many vastly different reasons why people do open source, and partly probably why we haven't "banded together to get paid" so to speak. For me, if I got donations that'd be great, but it'd not create a different sense of responsibility for my work, I'd keep doing exactly the same (unless I was explicitly hired as a cont…

So, in essence, I think you're saying that you choose a license depending on your goals for a project. Which seems reasonable. More reasonable than folks who release under a license, then complain when others do exactly what the license allows. I see a lot of "but give nothing back" complaints from some open source folk, but I've looked hard and I don't see a "give something back" clause anywhere, at least not in the…

> I don't see a "give something back" clause anywhere

You're right about that, but there isn't a "this software works" clause either :D

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

#762

Post by heurisko »

notRobot wrote: post #758
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…

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 files that allow them to be downloaded using composer rather than curl).

Fair enough if someone doesn't want to add metadata to allow their code to be downloaded by composer, but I disagree that that offers any security benefit.

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

#763

Post by Bolkan »

junon wrote: post #474
TranquilMarmot wrote: post #239

Earlier quoted context omitted.

The little `^` in version numbers in NPM's `package.json` file is such a bizarre choice. The fact that it by default installs all new dependencies with that means that builds on different machines at different times could result in _completely_ different artifacts.

I use an .npmrc in all of my repos that turns this off. It doesn't help nested dependencies but at least it reduces some of the headache.

Can you share it?

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

#764

Post by Flocular »

aahortwwy wrote: post #302
Beta-7 wrote: post #137

Earlier quoted context omitted.

At my last job we (InfoSec) had the devs fill out "ownership" forms for when they want to include something third-party into the product. Other than forcing the team to do due diligence on the third-party it also made them responsible for keeping it secure and them the people "at fault" if something went wrong due to it. While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful convers…

These sorts of "security" measures kill productivity and ultimately accrue (along with others) to the point where your organization moves so slowly that its lunch gets eaten by upstart competitors who aren't burdened by self-imposed make-work. I've seen it happen.* EDIT: * While working in infosec, I'll add.

Are you mitigating supply chain attacks otherwise? If yes, how?

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

#765

Post by ralferoo »

The real problem for a spiteful move like this is that it's unlikely to make people want to support his open source work at the risk he'll later destroy it, and companies are unlikely to want to employ him because of fears of him sabotaging the code base if he ever got upset and left on bad terms.

I can't really see any positive outcome for him personally on this, although ironically any of the big companies he's talking about are learning the lesson not to trust other people's code updates without auditing.

But maybe this will change the mindset in open source package managers that updating to the latest version is always best. The older approach of something like git submodule and sticking with a tried-and-tested version until you make a deliberate choice to update seems much more appealing now.

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

#766

Post by crate_barre »

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 large Fortune 500 company probably isn’t even paying the lowly developer enough who took the time to find a terminal colors package anyway. You really think this is the person that’s going to be able to lobby for dev budget? They are literally trying to keep their own god damn job.

It might be time we have a package marketplace like Steam that companies can subscribe to and independent developers can make some money via the marketplace.

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

#767

Post by marcus_holmes »

0x0nyandesu wrote: post #734
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…

You can say the same thing about the entire Linux stack

This is a false equivalence brought up every time anyone mentions how vulnerable the npm/gems/pip ecosystems are to supply chain attacks.

Linux code is always reviewed before deployment, goes through many eyeballs, people are careful about this. The same is not true of npm, or any of the other services (as this event clearly shows).

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

#768

Post by marcus_holmes »

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?

Pay the maintainers of the libraries you use, and have a contract with them that states their obligation to maintain and support your use of their code

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

#769

Post by 0x0nyandesu »

marcus_holmes wrote: post #767
0x0nyandesu wrote: post #734

Earlier quoted context omitted.

You can say the same thing about the entire Linux stack

This is a false equivalence brought up every time anyone mentions how vulnerable the npm/gems/pip ecosystems are to supply chain attacks. Linux code is always reviewed before deployment, goes through many eyeballs, people are careful about this. The same is not true of npm, or any of the other services (as this event clearly shows).

Eh that's not true. I use Gentoo so trust me most things are run by little dictators of their own little fiefdoms.

I'm talking about not just the kernel but all the various other things from libraries to servers to tools and everything in between.

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

#770

Post by Bolkan »

throwaway47292 wrote: post #742

create-react-app has thousands of transient dependencies, being worked on by maybe 40000 developers (possibly more), 1 in 100 people is a sociopath, and 1 in 100 is a psychopath, and looking at the general population around 1 in 100 is a criminal. There is selection bias in the open source community, but still, we can assume when you do `create-react-app` you are going to run the code of ~50 people that don't have yo…

I would but can't because '^'
Post reply on HN