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

21–30 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#21

Post by Lazare »

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 security breach was to blame and independently attempted to publish their own replacements for these packages.

No. Assuming everything in that excerpt is true (and I happen to know it's not, but that's not even relevant here), that wasn't the problem.

The problem is that NPM allowed packages to be re-uploaded by new authors after the initial versions had been spam filtered. Especially since allowing packages to be re-uploaded by new authors was the core issue of the left-pad debacle, and the one thing NPM said they'd fixed in response.

Let's summarise here:

1. NPM has a big issue

2. They claimed they had fixed it

3. They had not

4. In their post mortem they're pretending the issue doesn't exist

This guts any remaining trust I had in npm. Even if I wanted to trust them, they're not even admitting the problem exists; how am I meant to believe they're finally going to fix it? They've stopped even promising to fix this, and moved on to lies and denial.

Unacceptable. Literally. This is pushing me away from the node ecosystem because I am not prepared to accept this sort of weaponized incompetence from the primary package repo for node.

Re: Npm operational incident, 6 Jan 2018

#22

Post by tedivm »

ivraatiems wrote: post #18
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…

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

Afterwords NPM came out with a blog post[2] where they went out of their way to take as little blame as possible and basically said it was the developers fault. They said they "stand by [their] package name dispute resolution policy, and the decision to which it led"- basically ensuring that no developer should ever trust their repository in the long term, as they'll happily hand over any package name to a corporate entity if that entity asks for it.

The weird thing is that they claimed to make it impossible to "unpublish" packages, so that developers could no longer rage quit their site, but apparently they didn't extend that new requirement to their own "security" systems.

[1] http://azer.bike/journal/i-ve-just-liberated-my-modules/ [2] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Re: Npm operational incident, 6 Jan 2018

#23

Post by lend000 »

I think a major security improvement for npm and other package managers using almost exclusively open-source/ non-compiled code is to require the source code be linked from a popular open-source platform like Github and then to take the package directly from there, to ensure the code can be audited and nothing else can be snuck in.

Re: Npm operational incident, 6 Jan 2018

#26

Post by mdekkers »

busterarm wrote: post #12
simooooo wrote: post #3

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

Been discussed. Repeatedly. For years. Can't understand why it hasn't happened still.

Can't understand why it hasn't happened still.

https://github.com/npm/npm/pull/4016 - I read this as "it´s hard, and we don´t care." took them forever to look at and reject a patch that would have gotten the ball rolling

Re: Npm operational incident, 6 Jan 2018

#27

Post by regecks »

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 they introduced package signing, would packages would adopt it fast enough for users of packages to only use signed packages?

What happens when signing keys are lost or compromised? Do we need to use countersignatures from timestamping services as with other forms of code signing, so that CI systems do not break if a key is pulled?

I think this is very much not straightforward. npm+pgp may be well intentioned but seems grossly inadequate.

Re: Npm operational incident, 6 Jan 2018

#28

Post by cjbprime »

The last paragraph is good! The other paragraphs are bad. The two main ways they are bad are:

1) A system that detects "spam" and then allows for the complete removal of packages as if they never existed, allowing anyone to replace them, should never be described in the neutral terms used in this post. This system appears to be an existential threat to the company and project, and one of its largest mistakes. It won't take a long investigation to figure that out; it should be obvious today.

2) The claim that the security and integrity of these hijacked npm package names was not jeopardized appears to be 100% pants-on-fire false. If it is not false, I think npm's users are owed an explanation today of why it's false, rather than a bare assertion.

I know it's hard to be in the hot seat. No animosity to any of the humans involved.

Re: Npm operational incident, 6 Jan 2018

#29

Post by weaksauce »

theptip wrote: post #7
FunnyLookinHat wrote: post #4

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

It's standard operating procedure to elide the details of one's security posture. Would you expect Google's security team to provide a detailed list of all of the security procedures in place to prevent access to their network? Rejecting "security through obscurity" just means you shouldn't rely on obscurity alone. Obscurity + good security > good security alone, since it increases the threshold of time and ability t…

I saw a bit of a talk by a google engineer that laid out their overall strategy for securing the android app ecosystem. I don't think it's a hard and fast rule.

Re: Npm operational incident, 6 Jan 2018

#30

Post by Dylan16807 »

tedivm wrote: post #22
ivraatiems wrote: post #18

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…

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.
Post reply on HN