Post-mortem of this weekend's NPM incident
blog.npmjs.org
Post-mortem of this weekend's NPM incident
1–10 of 44 posts
Re: Post-mortem of this weekend's NPM incident
#2So, 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 published on npm.
That is a policy that is just begging for griefing.
Re: Post-mortem of this weekend's NPM incident
#3This 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 in to that number.
Re: Post-mortem of this weekend's NPM incident
#4This 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.
Re: Post-mortem of this weekend's NPM incident
#5This 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?
Re: Post-mortem of this weekend's NPM incident
#6So, 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…
> Seems like npm might want to review the policy that allows stuff like that to happen.
That's one of the things the post mentions as what they are doing.
Re: Post-mortem of this weekend's NPM incident
#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 packages. Did I miss where the remedy for this spam-removed-package-reuse was in the blog post?
Re: Post-mortem of this weekend's NPM incident
#8This 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'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.
Re: Post-mortem of this weekend's NPM incident
#9> we have policies against ever running SQL by hand against production databases—but in this case we were forced to do so
Uh... Add in the fact that staff are now trigger happy, since a single button can do a lot of damage.
Re: Post-mortem of this weekend's NPM incident
#10This 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.
When your code deployment model is effectively "download stuff from random websites", I feel like namespace recycling is the least of your worries.
(That is to say, trusting that any given named package that `npm install` downloads is what you think it is is really no different that trusting `wget https://example.com/thecode.tgz`. Even if you verify that the domain hasn't switched hands, you have no guarantee that the author's pipeline wasn't compromised, or that the author didn't add malware themselves. There's a reason Debian, Red Hat et. al. put a lot of effort into ensuring integrity of their repositories.)