Npm operational incident, 6 Jan 2018 • Hacker News Board

Re: Npm operational incident, 6 Jan 2018

#101

Post by detaro » Sun, Jan 07, 2018, 10:53 PM UTC

sumitgt wrote: post #78

> We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons, but here is a high-level overview. Isn't that the opposite of good practice? You shouldn't rely on obscurity. It's better to have the security processes out in the open so that it can be audited and flaws pointed out.

Discussing anti-spam/abuse systems in specific detail would be fairly unusual, can you name any larger operation that does?

There's a lot of questions open that are non-specific to that though, so I'd agree that they could be sharing more.

Re: Npm operational incident, 6 Jan 2018

#102

Post by slig » Sun, Jan 07, 2018, 10:54 PM UTC

julienfr112 wrote: post #88

Is it related to a package that write logs in colors and send visa card numbers to hackers ?

No, that article was a warning that a package like that could exist in the wild and nobody would notice. It doesn't actually exists, as the author states in the blog post.

Re: Npm operational incident, 6 Jan 2018

#103

Post by indigodaddy » Sun, Jan 07, 2018, 10:59 PM UTC

indigodaddy wrote: post #96

I've been meaning to set up a blog with hexojs for a few weeks now, and was seriously all set to install node and npm (don't do too much with node...), and start tinkering yesterday, and then I checked hacker news, and was like 'well sheeyit'...

I guess this would be safe enough probably:

https://github.com/billryan/docker-hexo

Re: Npm operational incident, 6 Jan 2018

#104

Post by phpnode » Sun, Jan 07, 2018, 11:00 PM UTC

rspeer wrote: post #92

0x0 wrote: post #13

How can they claim no malicious actors were involved when packages such as duplexer3 were apparently replaced with undesirable code as reported in https://news.ycombinator.com/item?id=16087126 ?

Are you saying that displaying a Bible quote, modified to refer to the fact that duplexer3 is gone, is "malicious"? I believe this was one of the cases of a community member stepping up to publish a package quickly so that malicious code wasn't published. Presumably they make the claim that none of the code was malicious because they checked.

from the blog post:

> the integrity of these 106 packages were never jeopardized.

are we operating with different definitions of jeopardy here? 106 packages were absolutely at risk of harm during this window. The fact that some community members stepped up is irrelevant, a bad actor could have done a lot of damage here. I think this blog post is completely disingenuous, and doesn't make me trust npm.

Re: Npm operational incident, 6 Jan 2018

#105

Post by ntonozzi » Sun, Jan 07, 2018, 11:01 PM UTC

gpsx wrote: post #37

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

Verdaccio [https://github.com/verdaccio/verdaccio] looks like a viable open source alternative. Presumably you could use it to download the packages you needed, then disable proxying to the NPM registry.

Re: Npm operational incident, 6 Jan 2018

#106

Post by strictnein » Sun, Jan 07, 2018, 11:03 PM UTC

no29 wrote: post #19

Shank wrote: post #8

> no malicious actors were involved in yesterday’s incident, and the security of npm users’ accounts and the integrity of these 106 packages were never jeopardized Maybe not in the incident itself, but the sheer fact that many of the packages were replaced by other people constitutes a jeopardization of applications that depend on NPM. The only reason why some big package didn't get replaced with code that exfiltrate…

it's beyond disingenuous and flat out dishonest for npm to say the integrity of the packages was never jeopardized. within minutes there were reports that packages had been replaced with questionable and malicious content. https://news.ycombinator.com/item?id=16087079 this is probably a good indication of how a much more serious security event would be treated by the organization.. just sayin

Yeah, I have no idea how they can even pretend to claim that.

Re: Npm operational incident, 6 Jan 2018

#107

Post by olefoo » Sun, Jan 07, 2018, 11:04 PM UTC

5h wrote: post #43

tedivm wrote: post #22

Earlier quoted context omitted.

Yeah, about two years ago NPM stole a package name from an existing user and gave it to a company to use. The user then said that if he can't trust NPM to actually treat package naming fairly then he was just going to delete all of his packages[1]. This broke a ton of packages on people (in part due to "left-pad" disappearing), so the community went ahead and registered/uploaded all of the packages to NPM again. Afte…

Just had a quick look - the "kik" package isn't in even use anymore - the whole thing was just drama theatre from by a messaging app I've never heard of. Despite it having 200 million users. Apparently.

In the US Kik has a pretty active userbase; but it's demographics skew older, poorer and more female and more rural. So that might be why you haven't heard of it.

Re: Npm operational incident, 6 Jan 2018

#108

Post by acemarke » Sun, Jan 07, 2018, 11:06 PM UTC

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?

I haven't actually used an NPM caching proxy myself. It looks like Artifactory does support acting as an NPM proxy. The other tools I've heard of are Sinopia, Verdaccio, and local-npm.

Addy Osmani has a related article at https://addyosmani.com/blog/using-npm-offline/ .

Re: Npm operational incident, 6 Jan 2018

#109

Post by noobermin » Sun, Jan 07, 2018, 11:07 PM UTC

pwaai wrote: post #33

Lazare wrote: post #21

Very displeased about this response. > In yesterday’s case, we got it wrong, which prevented a publisher’s legitimate code from being distributed to developers whose projects depend on it. We identified the error within five minutes and followed defined processes to reverse this block. Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or securi…

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.

Re: Npm operational incident, 6 Jan 2018

#110

Post by tzs » Sun, Jan 07, 2018, 11:08 PM UTC

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build.

Anyone know why they did it that way instead of giving each developer a subspace of the namespace that only that developer can publish under?

I'm thinking of the way it works on Java, where my package would be net.tzs.order_pizza, or GitHub (and numerous others) where it would be tzs/order_pizza.