Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

91–100 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#91
I'm trying to figure out whether node2nix [0] could help avoid package name/version hijacking vulnerabilities. Node2nix can convert a package-lock.json file to something called a Nix expression [1], like this [2], where each dependency has a checksum. The purpose is to make the Nix expression deterministic so that each Nix package is reproducible.

[0] https://github.com/svanderburg/node2nix

[1] https://nixos.org/nix/about.html

[2] https://github.com/svanderburg/node2nix/blob/22d0c19575ecd19...

Edit: fix link formatting

Re: Npm operational incident, 6 Jan 2018

#92
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.

Re: Npm operational incident, 6 Jan 2018

#93
post #90
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 ?

This is not a claim or a fact, that's probably an uneducated guess, npm is broken on so many levels they can't say anything for sure. [1] npm is full of fundamental bugs in their software, workflows, architecture, and community. We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package? Why is it possible to create new packa…

At least get the company name right if you have to make guesses about what they know internally and what they don't. (lol, and edited it silently so my comment looks dumb now)

Re: Npm operational incident, 6 Jan 2018

#94
post #5

"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?

The correct question should be: "what firewall and IDS do you use?"

Re: Npm operational incident, 6 Jan 2018

#95
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.

Yeah, I found this an important aspect of the article. I don't know anything about the culture at NPM, but this feels related to the mismanagement of communication with consumers/the public about the incident itself. i.e., being secretive for no good reason.

Re: Npm operational incident, 6 Jan 2018

#98

Lots of people are piling onto npm here. This reads to me like a fairly simple unintended consequence of what seemed like a good approach. Automated spam filters help to avoid dodgy packages. Spam filtering operates on heuristics so it’s sensible to not publicise how they work. The automated spam filter kills dodgy uploads, as these mostly happen on previously unused names a decision is made to not have the spam pack…

[deleted]

Re: Npm operational incident, 6 Jan 2018

#99

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'.

Re: Npm operational incident, 6 Jan 2018

#100
post #93
post #90

Earlier quoted context omitted.

This is not a claim or a fact, that's probably an uneducated guess, npm is broken on so many levels they can't say anything for sure. [1] npm is full of fundamental bugs in their software, workflows, architecture, and community. We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package? Why is it possible to create new packa…

At least get the company name right if you have to make guesses about what they know internally and what they don't. (lol, and edited it silently so my comment looks dumb now)

>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

> they know internally and what they don't.

They know internally that they do a lot of things badly and this will result in more disasters for npm and JS communities, that's for sure. Check out how GitLab fixed their backup failure. They made new software for testing backups, they live-streamed their work on youtube, they made at least 2 write ups on this case. They were totally transparent about their mistakes and fixes, everyone applauded them for this. What did we get from npm?

Post reply on HN