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

11–20 of 44 posts

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

#11

Post by colanderman »

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.

Package signing by the author helps, but not if (a) the author's key is compromised, or (b) the author acts in bad faith. With npm-style package registries, the risk of such an event increases with the number of dependencies your project has.

Better to (a) ship your code with explicit version and content dependencies (e.g. a SHA-256 of the package you expect to exist), or (b) delegate trust in upstream packages to fewer, more well-vetted, authorities (i.e. distro-style).

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

#12

Post by DanBC »

josephorjoe wrote: post #2

So, a spammer uploaded something containing copied data from a legitimate user and npm deleted everything from that user. Oy. Seems like npm might want to review the policy that allows stuff like that to happen. Even if a user violates the spam policy (which, to be clear, it seems the affected user in this case did NOT do), that hardly seems to be appropriate grounds for deleting everything the user has ever publishe…

Are "joe jobs" still a thing?

https://en.wikipedia.org/wiki/Joe_job

> A joe job is a spamming technique that sends out unsolicited e-mails using spoofed sender data. Early joe jobs aimed at tarnishing the reputation of the apparent sender or inducing the recipients to take action against them [...]

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

#13

Post by Klathmon »

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.

>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 upset californians)

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

#15

Post by Ajedi32 »

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.

Seems like they're only allowing name reuse in the case of spam packages. Not allowing name reuse in that case might result in lots of names being rendered permanently unusable by automated spambots.

Assuming no actual users are depending on packages which are literally just spam, I don't really see an issue with reusing the names of those packages.

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

#16

Post by avianlyric »

kodablah wrote: post #7

> At the time of Saturday’s incident, however, we did not have a policy to publish placeholders for packages that were deleted if they were spam. I see this acknowledgement, but I cannot find where they will remedy this by putting placeholders in place of spam removals. As a concession, maybe only placeholders for spam removals of packages that are older than X days or depended on (explicitly or transitively) by X pa…

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.

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

#17

Post by daurnimator »

DanBC wrote: post #12
josephorjoe wrote: post #2

So, a spammer uploaded something containing copied data from a legitimate user and npm deleted everything from that user. Oy. Seems like npm might want to review the policy that allows stuff like that to happen. Even if a user violates the spam policy (which, to be clear, it seems the affected user in this case did NOT do), that hardly seems to be appropriate grounds for deleting everything the user has ever publishe…

Are "joe jobs" still a thing? https://en.wikipedia.org/wiki/Joe_job > A joe job is a spamming technique that sends out unsolicited e-mails using spoofed sender data. Early joe jobs aimed at tarnishing the reputation of the apparent sender or inducing the recipients to take action against them [...]

Yep. I had one against me mid last year.

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

#18

Post by bhuga »

detaro wrote: post #5
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…

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.

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

#19

Post by cwmma »

josephorjoe wrote: post #2

So, a spammer uploaded something containing copied data from a legitimate user and npm deleted everything from that user. Oy. Seems like npm might want to review the policy that allows stuff like that to happen. Even if a user violates the spam policy (which, to be clear, it seems the affected user in this case did NOT do), that hardly seems to be appropriate grounds for deleting everything the user has ever publishe…

It wasn't a policy it was a spam heuristic
Post reply on HN