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

71–80 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#71

Post by djsumdog »

acemarke wrote: post #62
md224 wrote: post #41

Earlier quoted context omitted.

My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...

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?

Re: Npm operational incident, 6 Jan 2018

#73

Post by bennofs »

Why does a spam system delete packages that have already been in use for quite some time? I could understand if it blocked some newly updated ones, but it seems like it has deleted already existing packages that also were used by other packages?

Re: Npm operational incident, 6 Jan 2018

#74

Post by flavio81 »

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 "pinkie-promise" wasn't available. This is the full effective source code of pinkie-promise:

    module.exports = typeof Promise === 'function' ? Promise : require('pinkie');
Not just a NPM fault, but a fault of the js community as a whole for accepting systems made from hundreds of one-line packages, a sort of spaghetti code for the modern era.

Re: Npm operational incident, 6 Jan 2018

#75

Post by randyrand »

JustARandomGuy wrote: post #44
tedivm wrote: post #14

> Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or security breach was to blame and independently attempted to publish their own replacements for these packages. Ensuring the integrity of the affected packages required additional steps and time. That is such a bad response to this. The problem isn't that "well-meaning members of the communi…

+1 I think it's shocking how NPM tries to subtly shift fault to "well-meaning members of the npm community" for costing NPM "additional steps and time". Shame on npm. This shouldn't have even been possible after the azer/kik issue a few years back.

I'm not a javascript dev, but isn't NPM volunteer run? It seems odd to be shaming people who do something for you as a volunteer free service.

Re: Npm operational incident, 6 Jan 2018

#76

Post by always_good »

md224 wrote: post #41
N_A_T_E wrote: post #31

Earlier quoted context omitted.

I agree in principal about not relying on npm during deployment. For a novice, what is the best way to ship modules?

My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...

That would break when going cross platform for modules with native deps.

Re: Npm operational incident, 6 Jan 2018

#77

Post by tankenmate »

tedivm wrote: post #14

> Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or security breach was to blame and independently attempted to publish their own replacements for these packages. Ensuring the integrity of the affected packages required additional steps and time. That is such a bad response to this. The problem isn't that "well-meaning members of the communi…

"Those who cannot remember the past are condemned to repeat it" -- George Santayana

Now, it is easy enough to lob an aphorism but an event like this means that lessons previously learnt have been ignored (for whatever reason).

If you are going to build something that replicates or advances on previous systems the least you can do is study those systems to see what they did right and what they did wrong. In my opinion the Javascript ecosystem has produced some wonderful new systems that do things that have never been done before but in doing so they have wilfully ignored the past and didn't learn some basic lessons. In doing so they muddy the waters and in the end bring down the reputation of the whole ecosystem. I guess then it is not a huge surprise that a sizeable number of people feel that an unusually large number, as a percentage, of Javascript projects come and go and keep reinventing the wheel.

Re: Npm operational incident, 6 Jan 2018

#78

Post by sumitgt »

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

Re: Npm operational incident, 6 Jan 2018

#79

Post by Lazare »

glenjamin wrote: post #58

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…

> This reads to me like a fairly simple unintended consequence of what seemed like a good approach.

Yes, but you need to keep in mind:

1. This stuff is hideously important because getting it wrong is a incredibly serious security hole. Letting people publish a package with a name that other people are already requiring is a defcon 1 emergency.

2. They already had a major issue with this and said they had fixed it. You get, at most, one time when you can say "whups, we didn't realise how big an issue this was!".

3. It's their job to get it right. This is, literally, npm inc. It's not some hobbyists, or a service being provided by people in their spare time.

So when you say:

> The automated spam filter kills dodgy uploads, as these mostly happen on previously unused names a decision is made to not have the spam packages’ name remain taken.

I have to disagree. They needed to check how many times the flagged package had been downloaded, and after the left-pad debacle, they knew (or should have known) that.

They're not taking this seriously.

Post reply on HN