Post-mortem of this weekend's NPM incident • Hacker News Board

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

#41

Post by krapp » Fri, Jan 12, 2018, 2:22 PM UTC

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?

I'm suggesting NPM integrate Github's authentication API into their publishing process, to validate that the author owns a namespace if NPM doesn't already do that (I don't know, I don't use NPM.) If Bitbucket allows the same, then that's OK. The point is to have authors control namespaces, and NPM control package names but only validate namespaces. If namespaces are just another string that NPM controls and that can be handed out, revoked or taken over like package names then using them doesn't solve the intended problem at all.

Since NPM uses a centralized registry, though, some limitations would have to be imposed, and allowing multiple sources would mean allowing for conflicts between github:google/package and bitbucket:google/package. Ideally, namespaces should be unique and canonical, and the simplest way to accomplish that is just to allow publishing to a single source.

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

#42

Post by Vinnl » Fri, Jan 12, 2018, 5:21 PM UTC

h1d wrote: post #38

Vinnl wrote: post #27

Earlier quoted context omitted.

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?

Hmm, I'm not sure if I can follow your question, but I'm guessing that they're already planning to do what you want?

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

#43

Post by sitkack » Fri, Jan 12, 2018, 5:28 PM UTC

JonathonW wrote: post #8

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.

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.

I'd also like a bunch of checks applied to my use of that registry.

1. only packages > nK downloads 2. only packages with tests 3. only packages with publicly available code that is same that I am downloading 4. only packages with > nnn stars, forks, issues, pull requests

All are just proxies for being a valid node in a dependency graph.

And like to know if any transitive dep violates my inclusion rules.

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

#44

Post by mbessey » Sat, Jan 13, 2018, 1:21 AM UTC

detaro wrote: post #34

bhuga wrote: post #18

Earlier quoted context omitted.

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?

Yes, and there are dozens of spam packages registered (and deleted) every day.