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

101–110 of 1001 posts

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

#101

Post by xienze »

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

A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.

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

#103

Post by dathinab »

throw_m239339 wrote: post #83
mjlawson wrote: post #58

Earlier quoted context omitted.

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.

> 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. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.

Except if they have reason to believe the code was uploaded with the permission of the copyright holder.

The they have gotten the right for npm to distribute the source code in context of npm.

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

#104

Post by oblio »

detaro wrote: post #65
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

How does that solve the issue here of new broken versions of packages being published?

That's another JS ecosystem widespread malpractice.

Autobumping versions, or version ranges as they're called in Maven land.

Dependencies should only use fixed versions and all updates should be manual.

You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).

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

#105

Post by throw_m239339 »

tablespoon wrote: post #37
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.

> 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. It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers." I use packages…

> Does the JavaScript ecosystem have anything like Apache Commons? I'm guessing not, but it probably should.

This isn't a Javascript problem, this is a node problem. Node is just a Javascript platform among many. The fact that the node community decided to go with all these "nano packages" has absolutely nothing to do with Javascript. Nothing forced Node, the distribution, to come with such a barebone standard library. Absolutely nothing... but the idea of being dependent of NPM which was orchestrated by NPM founders, that's how NPM, a private business made money and eventually sold to Microsoft.

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

#106

Post by ses1984 »

detaro wrote: post #65
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

How does that solve the issue here of new broken versions of packages being published?

You shouldn't blindly pull updates into production, how do you know if a non-malicious update breaks your app if you don't do any basic testing first?

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

#107

Post by trexd »

throw_m239339 wrote: post #76
trexd wrote: post #38

Why not just change the license to GPLv3 for the upcoming version?

GPL for students and open source projects, paid license for orgs and companies. GPL itself isn't really a way to get paid for your work.

I was speaking more to preventing companies from using your open source work, but I guess in this instance the emphasis is on getting paid.

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

#108

Post by bastardoperator »

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 would anyone want to deal with him after this stunt is beyond me.

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

#109

Post by iainmerrick »

Flocular wrote: post #78

Imagine they introduced something worse. Could any developer explain to a manager why you needed to import this package? "Why do we need colors there?", "Why can't we make that colored ourself?"

“Why are you writing all this stuff by hand? Isn’t there a package for that?”

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

#110

Post by maxwell86 »

laurowyn wrote: post #79
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 you want, if the repo/vendor/maintainer pulls the release then you're not getting access to your dependencies at all. If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.

> if the repo/vendor/maintainer pulls the release

If your package system allows this switch to another one, like, right now.

NPM, Cargo, etc. don't allow this (they "unlist" versions, but they don't "remove" them, i.e. you can't search for them, but they are still there).

Post reply on HN