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

51–60 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#51

Post by auggierose »

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"

They are Javascript programmers ...

Re: Npm operational incident, 6 Jan 2018

#52

Post by gedy »

cobbzilla wrote: post #36

How difficult is it to run your own private npm repo? Looks like that's what security-conscious folks should be doing, given this response. Any pointers/gotchas/battle stories much appreciated.

It's doable, and one very good option is Sonatype Nexus https://www.sonatype.com/download-oss-sonatype

The one issue I've seen over the years is it seems npm Inc does not officially sanction on site npm repos (presumably to help monetize their private hosted repos), and finding info on how to set up a private repo is lacking.

Re: Npm operational incident, 6 Jan 2018

#53

Post by atmartins »

auggierose wrote: post #51
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"

They are Javascript programmers ...

Not sure how that's relevant.

Re: Npm operational incident, 6 Jan 2018

#54

Post by Sephr »

> who believed that a malicious actor or security breach was to blame

This was a security breach. Their anti-spam system should block repos by freezing the module name and returning blank files, not by deleting the entire module and subsequently allowing anyone to upload new modules. This is leftpad all over again.

Update: Woah, so I was checking out my old NPM namespaces and apparently someone took control over https://www.npmjs.com/package/filesaver.js

Re: Npm operational incident, 6 Jan 2018

#56

Post by revelation »

regecks wrote: post #27
simooooo wrote: post #3

They need to pull their socks up and start signing these packages

What would signed packages have achieved in this incident? Who needs to sign the packages? The developers of the packages, right? Otherwise developer credential compromise subverts the entire point. Which keys are authorized to sign for which packages? How to prevent credential compromise from affecting those authorizations? What's the difference between a signed legitimate package and a signed malicious package? If…

No one is asking for perfect, just an ssh style warning of "the key of the system you are connecting to changed from last time" would be a good start. Implementing that is trivial, straightforward, requires zero setup and would have easily prevented the copycats here.

Re: Npm operational incident, 6 Jan 2018

#58

Post by glenjamin »

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 packages’ name remain taken. Among other things this stops the spammers from leaving all the good names blocked.

The spam code gets a false positive and the above logic kicks in, leaving previously used names now available. This is noticed and corrected within a few hours.

The npm team will likely improve their spam filtering heuristics and also ensure that formerly good packages that get spam flagged do not release their names - they have indicated roughly this on Twitter.

This only just happened, and it’s the weekend, so I’d expect a full write up will be released during the week when they’ve had time to do a post-mortem and work through the salient points.

Re: Npm operational incident, 6 Jan 2018

#59

Post by allover »

tedivm wrote: post #32
Dylan16807 wrote: post #30

Earlier quoted context omitted.

I don't think the dispute resolution process makes them untrustworthy. It's an annoyance. It's the unpublishing that's a huge security flaw vector, and the fact that they didn't actually fix what they claimed is pretty bad.

To me it's a trust issue. Their dispute policy breaks trust in two ways- 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. What you say is also a problem. The fact that they…

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

> 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better.

I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. When they handed over 'kik' it wasn't in the same league as 'left-pad' which was widely depended upon.

> What you say is also a problem. The fact that they claimed to have solved the unpublishing problem when they apparently hadn't is pretty huge

I agree it sucks, but the fact is they 'prevented unpublishing' to bug-fix one vector for this problem, but then introduced a bug in process that appears very similar to unpublishing. If you've never had this sort of thing happen to you as a software dev, (had some stakeholder question 'but I thought you'd fixed X') you're very very lucky.

> as is the fact that the flaw exists to begin with.

Easy to criticise in hindsight. At the time of left-pad, several other package registries (e.g. PyPI) also allowed unpublishing.

Post reply on HN