Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

Post reply on HN
Print view View original

111–120 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#111

Post by strictnein »

emerged wrote: post #69

I left an Ethereum related project precisely because of the house of cards feel of it being built off JS and npm modules. They're a great example of how a project can be exploited by a malicious module which could proceed to extract all the tokens. If my hat is black, I'm writing a daemon which monitors relevant npm modules and uploads subtlely modified versions if and when the possibility to do so occurs again. Part…

> If my hat is black, I'm writing a daemon which monitors relevant npm modules and uploads subtlely modified versions ...

I started sketching out one yesterday, and then thought "What am I going to do with this? Probably just get in trouble" so I stopped.

Re: Npm operational incident, 6 Jan 2018

#112

Post by Qerub »

djsumdog wrote: post #71
acemarke wrote: post #62

Earlier quoted context omitted.

Committing your `node_modules` is a bad idea. The best answer is to either use an offline cache of package tarballs that have been committed to your repo, or an NPM caching proxy. Yarn has an "offline mirror" feature built in, and Shrinkpack is a tool that can create an offline mirror based on an npm-shrinkwrap.json file. I wrote about using Yarn's offline mirror here: http://blog.isquaredsoftware.com/2017/07/practic…

I know you can use JFrog/Artifactory to cache pulls of Jar files from maven repos, as well as Docker images. Does JFrog support node?

Yes, JFrog Artifactory supports npm and so does Sonatype Nexus. More info:

https://www.jfrog.com/confluence/display/RTF/Npm+Registry https://help.sonatype.com/display/NXRM3/Node+Packaged+Module...

Re: Npm operational incident, 6 Jan 2018

#113

Post by noobermin »

With this and leftpad etc., I think it's time for the tech community to remember Java and Oracle, Sourceforge, etc., or look it up if you are too young to remember. It is beneficial to learn from history instead of making the same mistakes all over again.

Centralized trusted authorities cannot be trusted if they are private companies who don't answer to you. If you aren't paying them and you don't have a management position in said company, things like this will happen.

Re: Npm operational incident, 6 Jan 2018

#114

Post by reificator »

platz wrote: post #5
FunnyLookinHat wrote: post #4

"We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons..." - Security by obfuscation? That's not security. Your protocols and processes should stand up even if made public.

What is your home address and phone number?

> What is your home address and phone number?

Neither of those are security systems. That's like asking for their password and claiming you've proven security through obscurity.

The idea behind dismissing obscurity is that if everything but private tokens were exposed, your system should still remain secure.

Re: Npm operational incident, 6 Jan 2018

#115

Post by vePhi4le »

djsumdog wrote: post #71
acemarke wrote: post #62

Earlier quoted context omitted.

Committing your `node_modules` is a bad idea. The best answer is to either use an offline cache of package tarballs that have been committed to your repo, or an NPM caching proxy. Yarn has an "offline mirror" feature built in, and Shrinkpack is a tool that can create an offline mirror based on an npm-shrinkwrap.json file. I wrote about using Yarn's offline mirror here: http://blog.isquaredsoftware.com/2017/07/practic…

I know you can use JFrog/Artifactory to cache pulls of Jar files from maven repos, as well as Docker images. Does JFrog support node?

yes: https://www.jfrog.com/confluence/display/RTF/Npm+Registry

Re: Npm operational incident, 6 Jan 2018

#116

Post by macintux »

allover wrote: post #86
dozzie wrote: post #68

Earlier quoted context omitted.

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. > You can as long as your package name isn't trademarked or likely to confuse users installing the package. Trademarked where exactly? You know, there's quite a lot of world beside US. > I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. What m…

> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name. [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

How many times does it have to happen to warrant concern?

Trust, once broken, isn't quickly restored.

Re: Npm operational incident, 6 Jan 2018

#117

Post by reificator »

allover wrote: post #80
gpsx wrote: post #37

I've used NPM only a little but this scares me. What are NPM alternatives?

NPM shouldn't scare you. Simple fact is you should not be relying on ANY package registry at the time of deployment.

> NPM shouldn't scare you.

It absolutely should, just like any dependency on any other third party code or servers. Especially when they regularly have incidents like this.

> Simple fact is you should not be relying on ANY package registry at the time of deployment.

This is true, but doesn't prove the previous claim.

Re: Npm operational incident, 6 Jan 2018

#118

Post by netsharc »

flavio81 wrote: post #74

It is really another embarrasment for NPM, considering that this is not the first time something similar happens (see: left-pad issue, 23 march 2016) So they learnt zero from it. Then, WHEN ARE THEY GOING TO SIGN THOSE PACKAGES? Zero, nothing. They didn't learn from mistakes, they don't listen. NPM is still open to all sorts of malicious use. Besides NPM problems, yesterday many packages won't work because package "p…

So the kiddies haven't learned, huh? The whole left-pad debacle was because of a package that has 1 single function: it pads your string to a certain length by prefixing characters. (Writing this I wonder who made right-pad). And it broke almost everything.

Re: Npm operational incident, 6 Jan 2018

#119

Post by krapp »

yoodenvranx wrote: post #99
flavio81 wrote: post #74

It is really another embarrasment for NPM, considering that this is not the first time something similar happens (see: left-pad issue, 23 march 2016) So they learnt zero from it. Then, WHEN ARE THEY GOING TO SIGN THOSE PACKAGES? Zero, nothing. They didn't learn from mistakes, they don't listen. NPM is still open to all sorts of malicious use. Besides NPM problems, yesterday many packages won't work because package "p…

Someone should grab the 100 most used packages which contain less than 30 lines of code, merge it into one package and call it 'npm standard library'.

Guess I'll be that guy: https://xkcd.com/927/

Re: Npm operational incident, 6 Jan 2018

#120

Post by [deleted] »

noobermin wrote: post #109
pwaai wrote: post #33

Earlier quoted context omitted.

With all that money they've raised, it's puzzling why they don't take PR seriously. I guess they have a mentality of "where the fuck else are you gonna go, the node community is tightly coupled to our service"

It's almost as if the tech community has to learn once again centralized systems with a trusted authority at the top can't be trusted when that trusted authority makes mistakes.

[deleted]
Post reply on HN