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

951–960 of 1001 posts

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

#951

Post by dcow »

gnubison wrote: post #911
dcow wrote: post #887

Earlier quoted context omitted.

I pretty much agree with you especially on the point that there are far more effective and nuanced ways to for the maintainer to have made their point, like relicensing (imagine what would happen if the license suddenly became AGPL and everyone at big corps automatically updated without checking the new license—it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and pr…

> Our society very much puts a premium on protecting victims. … is this a bad thing?

Not in isolation but it’s important to understand. It can and is abused by people who know how the meta game is played. The biggest thing for me is that it pretty frequently results in an internally inconsistent worldview, and that is a bad thing.

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

#952

Post by dcow »

rezonant wrote: post #923
dcow wrote: post #887

Earlier quoted context omitted.

I pretty much agree with you especially on the point that there are far more effective and nuanced ways to for the maintainer to have made their point, like relicensing (imagine what would happen if the license suddenly became AGPL and everyone at big corps automatically updated without checking the new license—it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and pr…

> it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and probably rake in more than a 6 figure salary… but I digress) For these particular packages? Very unlikely.

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?

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

#953

Post by ehnto »

dvdcxn wrote: post #807
ehnto wrote: post #551

Earlier quoted context omitted.

They can still delete the package from NPM can't they?

Even if they did they're not 'breaking your app in minutes', as if all live apps which use that package are suddenly going to poll npm for deleted packages. That's absurd.

Of course that's absurd, that's not really the core of the argument though. I would still consider it breaking my app if I now need to go replace that package somehow, or pull it from some archive, before I can re-deploy my application.

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

#954

Post by rezonant »

dcow wrote: post #952
rezonant wrote: post #923

Earlier quoted context omitted.

> it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and probably rake in more than a 6 figure salary… but I digress) For these particular packages? Very unlikely.

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.

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

#955

Post by mastazi »

selfhoster11 wrote: post #858
mastazi wrote: post #430

My takeaway from this story is that I never really gave a thought about the fact that Github can close your account... And since on Github you are not allowed to have multiple accounts (e.g. personal vs work account), when that happens they are taking away your ability to work. I am going to set up a self hosted git server for my personal projects straight away. I am thinking about Gitea, any one can share their expe…

Gitea is very lightweight, easy to get started with, and all-around fantastic Git host, although it does less than Gitlab (I don't think it does CI as a built-in feature, for instance). The web interface is lightning-fast, almost as fast as a native app (no exaggeration here). I'd you have a little spare RAM and a CPU core, it's a great start to self-hosting Git. I have been running it for at least a year, and liked…

Thank you this helps a lot! Especially when you talk about the requirements and the fact that Gitlab has CI.

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

#957

Post by tluyben2 »

heurisko wrote: post #815
notRobot wrote: post #778

Earlier quoted context omitted.

> There is nothing inherent in using packages that means you have to blindly trust the code Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood". 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 wr…

> 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 installs that many files on npm install). Package management is great; it works well with NuGet for instance. But those are a sane community; no one used leftpad and such, so the tree of source to audit is not so large, not counting MS, but then again, you are not auditing nodejs are you? Npm is worse than gems, nuget, whatever php has etc simply because the community is pretty broken in as much that everything has to be a package and, even though you can type the functionality faster than you can search for it (yeah yeah whine tests whine docs: for leftpad, nobody cares about those things; it's trivial functionality), people use those.

Now faker (don't know colors) is non trivial: question is, what makes this to happen here and not in, say, nuget popular packages? Is it still/again the community or something else...

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

#958

Post by raesene9 »

sailingparrot wrote: post #846
raesene9 wrote: post #744

Earlier quoted context omitted.

I'm sure this case is clear, my point was around the wider principal that by going down this line GH set themselves up as arbiter of "malice" To take a trickier example, say a GH user has a lib, then decides to re-architect it, breaks the API and for their own purposes pushes it to an existing version, breaking all other use of it. Now that's a nasty thing to do, but is it malice? Another, real-world, example is I kn…

> By stepping into this area GH are going to have to find answers to this a I think they already have, those 2 examples you mentioned already happened and were dealt with. I think intent is important to take into consideration, since after all that is the definition of malicious: intent to cause harm. Your first example clearly has no intent to cause harm. That case probably happened thousands of time already since n…

The thing is, intent isn't always clear and oftentimes Github are unlikely to have all the context needed. It's easy to determine with simple examples, the real world is often messier.

For example in that first case, say all they had was a wave of people saying "x broke my application" it would look a lot like the case in the article, and they'd have to dig in to find out it was just a bad API change without semver being followed.

Also requires Github to have a staffed department to deal with this, now they've established themselves as the arbiters.

For me, there's a split between a repository (NPM) and a hosting company (Github). For this case I'd have forked the repo, rolled back the malicious change in the fork, and hooked the fork up to NPM, and leave the original GH account alone. That solves the problem of the breakage, without getting in to banning whole GH accounts.

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

#959

Post by randomswede »

Was the developer doing something "outside what they should be allowed to"? No. It's their package. I would argue that intentionally introducing a breaking change (I would count "go into endless loop" as "no longer performing the same semantic operation") should also be coupled with a "bump major version".

Was the developer being an arse? Yes, definitely.

Technically and morally correct are two very different things. And doing this sort of thing does have an impact on your reputation I suspect that the dev now have limited at least a few possibly-lucrative jobs down the line.

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

#960

Post by kavaruka »

herbst wrote: post #806
rk06 wrote: post #676

Earlier quoted context omitted.

In browser land, the less code you ship, the better. Removing dead js code is hard, because of its dynamic nature and using common js imports making it harder for treeshaking algorithms. So, people had incentive to write and use smaller packages. Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build

> In browser land, the less code you ship, the better That's kinda funny. These node tools I run into these days usually take forever to install, waste a lot of space due to creating their own package mirror and generally are prone to break because of dependencies. There is usually nothing tiny about them, even thought they only have a few lines of code.

usually the "node_modules" folder (with tons of files) is not deployed on production, for front-end application that are going to run in the browser

when we make a build for the browser we bundle all dependencies into fewer files that only contain the code that is used

Post reply on HN