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

771–780 of 1001 posts

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

#771

Post by marcus_holmes »

bastardoperator wrote: post #108

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

How many other maintainers are getting increasingly annoyed at the users of their code? Entitled users demanding changes to fit their use cases, megacorps using the code for free, other megacorps forking the code and launching it as a commercial service, we've been hearing for years about the problems of being an OSS maintainer.

Focusing on the troubles of this one person is a mistake. Of course the more "unbalanced" individuals will crack first. But we should expect more and more to go the same way (not necessarily by sabotaging their code though).

This model of software development is unsustainable.

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

#772

Post by 0x0nyandesu »

mid-kid wrote: post #749
0x0nyandesu wrote: post #734

Earlier quoted context omitted.

You can say the same thing about the entire Linux stack

Not really, individual package developers don't have as much inmediate control over the repository's state as they do with NPM. Packages go through a review by one of the trusted developers and sometimes automated QA and testing (including as of late reproducibility testing, i.e. does the source match the binary?), before being uploaded to the repository. If you can't trust the team behind the distro, then sure, your…

I use Gentoo which uses portage the package manager and the way portage works is it pulls source then compiles. Source is rarely checked by everyone. Small packages exist as well. Many Linux distro simply barrow binaries from "trusted" sources. The entire eco system is really a deck of cards.

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

#773

Post by maze-le »

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…

> At the very least, it takes them under a minute to break your app, simply by deleting their package.

Not really, if you pin your versions exactly and don't do auto-updates. This also means that you have to update your packages manually and inspect what the latest versions are doing -- which is good practive anyway. NPM packages can not be depublished any longer as far as I know.

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

#775

Post by kodemager »

amyjess wrote: post #713
kodemager wrote: post #701

Earlier quoted context omitted.

I think it’s a bad stunt that outlines an issue with mega corps using oss and blindly updating their packages. Or anyone blindly updating their packages really. But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.

GitHub is private property, and they have the right to eject anyone from their property for any reason or even no reason at all. And the code is open-source under the MIT license, so GitHub can do with it as they see fit.

The MIT license doesn’t give you the right to claim ownership over someone else’s code.

You can copy it and claim ownership over that, but it doesn’t allow you to remove the author from their work and then keep the work as your own.

The author has a right to delete it if they want to.

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

#776

Post by maze-le »

bastardoperator wrote: post #108

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

> why would anyone want to deal with him after this stunt is beyond me

_faker_ is already gone from our project. The parts of faker that we were using were almost trivial to implement ourselves... probably should have done that from the start.

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

#777

Post by kodemager »

Too wrote: post #704
kodemager wrote: post #701

Earlier quoted context omitted.

I think it’s a bad stunt that outlines an issue with mega corps using oss and blindly updating their packages. Or anyone blindly updating their packages really. But I don’t see how GitHub has the right to suspend him and rewind his work. I mean, that has to be a copyright infringement if there ever was one.

A stall owner who deliberately injects poison into their apples should rightfully be thrown out of the Bazaar. Regardless if the apples are given for free or not.

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

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

#778

Post by notRobot »

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…

> 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 written with this in mind - with extensive commenting and documentation).

> neither does providing a package mean you have to accept any more responsibility

Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. 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 likelihood of any possible bugs in the code getting caught.

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

#779

Post by marcus_holmes »

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

Earlier quoted context omitted.

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.

OK, but none of those little fiefdoms are "Linux".

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

#780

Post by kzrdude »

josephcsible wrote: post #506
betwixthewires wrote: post #495

Earlier quoted context omitted.

It's not yours? Really. They own it now because they host it for you? So some ToS could override the software license for your project? In that case I don't see why anyone would use github, ever.

Be specific about what you mean by "it". The code you wrote is yours, but their copy of the repository is not yours. And GitHub's TOS does require that you give them certain rights to use the code you put in their repositories, regardless of whether your chosen license would have given them those rights anyway.

But what about the "github identity"? When github is used for authentication on other sites, it may come to a point where you have a reasonable right to continue to use your github identity, even if other github functionality is turned off.

I for one think that it makes sense - if I have an identity on github, it can only be turned off gradually, not immediately.

I would say, maybe suspend github services for the account and put a timer - 30 days - on suspending the github identity too.

Post reply on HN