Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Post-mortem of this weekend's NPM incident

blog.npmjs.org

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Post-mortem of this weekend's NPM incident

#31

Post by philipwhiuk »

hyperpape wrote: post #30
JonathonW wrote: post #8

Earlier quoted context omitted.

I'd like to see a package registry with (1) Github-style author-namespaced packages, and (2) package signing (i.e. if an author starts signing packages with a different key, I'd like to know about it). Maybe integrate the latter with Keybase to help users decide if they should trust a key. I don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.

(1) has the consequence that names are associated with the original creator long after they may no longer be involved. Package signing I can't tell if it's a good idea or not. It would require you to accept a new key in this case, but that is going to happen super frequently with NPM, inducing alert fatigue, and it doesn't do anything to prevent the authors' publishing credentials getting stolen.

(1) big projects just get moved over time.

e.g. philipwhiuk/gnome moves to gnome/core and there's a version published to philipwhiuk/gnome that pulls in gnome/core

Re: Post-mortem of this weekend's NPM incident

#32

Post by krapp »

Klathmon wrote: post #13
smt88 wrote: post #4

Earlier quoted context omitted.

Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience. If npm packages used a Github-style "author/package" format, name collision would never be an issue again.

>If npm packages used a Github-style "author/package" format, name collision would never be an issue again. They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version) But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very…

>But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians)

The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner.

No one should be able to "take" google/ since the actual Google already owns github.com/google.

Re: Post-mortem of this weekend's NPM incident

#33

Post by aidenn0 »

bhuga wrote: post #18
detaro wrote: post #5

Earlier quoted context omitted.

They allow deletion of packages for 24 hours without staff involvement, there is nothing said about a time limit on republishing after deletion?

From the response steps: > Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name.

But they also have a policy of replacing deleted package names with placeholders, which was not currently enforced for spam-deletions. The cooldown should give them 24 hours to discover any remaining holes in that policy.

Re: Post-mortem of this weekend's NPM incident

#34

Post by detaro »

bhuga wrote: post #18
detaro wrote: post #5

Earlier quoted context omitted.

They allow deletion of packages for 24 hours without staff involvement, there is nothing said about a time limit on republishing after deletion?

From the response steps: > Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name.

Oops, missed that part. Guess the logic is that for spam-packages, there isn't going to be anyone relying on them and it would be a waste of namespace space to allow spammers to fill it up?

Re: Post-mortem of this weekend's NPM incident

#35

Post by TomMarius »

krapp wrote: post #32
Klathmon wrote: post #13

Earlier quoted context omitted.

>If npm packages used a Github-style "author/package" format, name collision would never be an issue again. They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version) But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very…

>But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians) The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner. No one should be able to "take" g…

That would make a connection between Github and NPM. What if I want to use Bitbucket?

Re: Post-mortem of this weekend's NPM incident

#36

Post by croon »

Klathmon wrote: post #13
smt88 wrote: post #4

Earlier quoted context omitted.

Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience. If npm packages used a Github-style "author/package" format, name collision would never be an issue again.

>If npm packages used a Github-style "author/package" format, name collision would never be an issue again. They have that, and many are finally starting to take advantage of it (with babel being the most prominent with their latest version) But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very…

The issue isn't people assuming that every alias on the internet is truthful, very few people (hopefully) do.

The problem is a package URI being reused without me realizing, and that problem would be solved.

Re: Post-mortem of this weekend's NPM incident

#37

Post by tylerhou »

TomMarius wrote: post #35
krapp wrote: post #32

Earlier quoted context omitted.

>But this doesn't completely "fix" the problem, since the exact same conflicts can still happen with the "author" name (if someone takes "google\" there are going to be some very upset californians) The idea is that the author name maps to an actual repo and should serve as a second layer of authentication outside of NPM's control. The namespace should belong to the repository owner. No one should be able to "take" g…

That would make a connection between Github and NPM. What if I want to use Bitbucket?

Keep a git mirror of your Bitbucket repository on GitHub.

Re: Post-mortem of this weekend's NPM incident

#38

Post by h1d »

Vinnl wrote: post #27
dumbmatter wrote: post #23

Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name. Why not infinity hours? I don't get it.

If it's a spam package that gets deleted, that would mean you'd quickly run out of available names.

Why can't they just reuse when it is apparent the case is harmful (as in, people complain and check number of downloads and dependent packages) by blocking the name and disallow reuse for any other cases?

Re: Post-mortem of this weekend's NPM incident

#39

Post by testplzignore »

kodablah wrote: post #29
avianlyric wrote: post #16

Earlier quoted context omitted.

They have added a 24hour re-publishing cooldown for all package removals regardless of reason. Exceptions are made for the original publisher and npm staff. Explained somewhere near the bottom of the post, basic rational is that it gives them time to notice fuckups and fix them.

This does not alleviate the issue where you can reuse package names. I suppose they believe what they mark as spam packages won't be used enough or is already bad enough that reusing the name is harmless. And they probably also believe that they can catch fuckups in a day. I don't think either are necessarily true and are only true in this case because it hit popular dep trees. But what happens when something is erro…

My guess is that the cost of the placeholders is indeed what is driving their decision, though perhaps it is a premature optimization.

Maybe they've had situations where a spammer has created a very large number (millions, billions?) of packages. It's possible that the majority of user submissions are automated spam from botnets. I would assume npm has some mitigations in place to prevent this abuse in the first place, such as rate limiting and captchas, though maybe that's not enough to stem the tide.

Though, given that they say they have humans doing the package deletion, that makes me think that the number of spam packages created can't be that high. Certainly not high enough to outweigh the risks of package name reuse. Increase your prices a few pennies a month so you can afford to store the placeholders forever.

Re: Post-mortem of this weekend's NPM incident

#40

Post by parenthephobia »

smt88 wrote: post #4
bhuga wrote: post #3

This is a good post-mortem with clear, policy-based remediations. Nicely done. I wonder why they are only preventing republishing for 24 hours. Is there a good reason to allow a package namespace to be recycled with less than, say, a week? Is it based on the assumption that the only case where it comes up is during an incident, and 24 hours is enough time to assume an incident will be resolved? I'm curious what went…

Why allow namespace recycling at all? The potential harm is high and the potential benefit is some slight convenience. If npm packages used a Github-style "author/package" format, name collision would never be an issue again.

I think package URIs should include a secure hash of their contents.

Although you won't get updates without asking for them - I'm not sure that's a bad thing - you can be assured that you'll either get the package you were expecting or no package at all.

Post reply on HN