Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

41–50 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#41
post #31
post #24

Npm isn't ready for production use. If you're going to use it you either need to ship the modules you need or run it against a private repo of modules.

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

Re: Npm operational incident, 6 Jan 2018

#43
post #22

Earlier quoted context omitted.

> The problem isn't that "well-meaning members of the community" decided to upload packages. The problem is that when their system decides that a package shouldn't be up it completely removes the package, as if it never existed, and allows the namespace to be reused immediately. Those "well-meaning members" should not even be able to hijack packages this way, as it means the people who aren't "well-meaning" can also…

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.

Re: Npm operational incident, 6 Jan 2018

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

Re: Npm operational incident, 6 Jan 2018

#45
post #22

Earlier quoted context omitted.

> The problem isn't that "well-meaning members of the community" decided to upload packages. The problem is that when their system decides that a package shouldn't be up it completely removes the package, as if it never existed, and allows the namespace to be reused immediately. Those "well-meaning members" should not even be able to hijack packages this way, as it means the people who aren't "well-meaning" can also…

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…

This is exactly the incident I was thinking of, thank you.

It is bizarre that npm hasn't resolved these kinds of situations by now. Makes me glad I've continued to stay away from that ecosystem.

Re: Npm operational incident, 6 Jan 2018

#46
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…

Is the same people who also have problems with white, male developers (except themselves)?

No. Incompetence can crop up under any ideology.

Re: Npm operational incident, 6 Jan 2018

#47
post #27
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…

Android and the Google Play store works pretty well. The systems "locks on to" a public key signature so further updates for a given app must be signed with the same key. That would fix the problem with reproducible builds here. Only adding new top level packages to a project for the first time is at risk then.

Re: Npm operational incident, 6 Jan 2018

#49
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…

[deleted]

Re: Npm operational incident, 6 Jan 2018

#50
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?

445 12th Street, SW Washington, DC 20554

1-202-418-1440

Post reply on HN