TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Post-mortem of this weekend's NPM incident

132 点作者 txmjs超过 7 年前

7 条评论

bhuga超过 7 年前
This is a good post-mortem with clear, policy-based remediations. Nicely done.<p>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&#x27;m curious what went in to that number.
评论 #16125419 未加载
评论 #16125565 未加载
josephorjoe超过 7 年前
So, a spammer uploaded something containing copied data from a legitimate user and npm deleted everything from that user. Oy.<p>Seems like npm might want to review the policy that allows stuff like that to happen.<p>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.<p>That is a policy that is just begging for griefing.
评论 #16125595 未加载
评论 #16125750 未加载
评论 #16126450 未加载
cremp超过 7 年前
&gt; we have policies against ever running SQL by hand against production databases—but in this case we were forced to do so<p>Uh... Add in the fact that staff are now trigger happy, since a single button can do a lot of damage.
dumbmatter超过 7 年前
<i>Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name.</i><p>Why not infinity hours? I don&#x27;t get it.
评论 #16127450 未加载
kylemuir超过 7 年前
&gt; Our first action, which began immediately after the incident concluded, was to implement a 24-hour cooldown on republication of any deleted package name<p>I don&#x27;t understand this. Why hard delete packages at all? Soft deleting feels like it would be easier and would stop people republishing with the same name.<p>They could also bake their warning process for dependent libraries (i.e. &quot;this package is gone!&quot;) into the soft delete process.
carsonreinke超过 7 年前
I feel like a project that could help with this to identify package importance by the dependents and downloads.
评论 #16126526 未加载
kodablah超过 7 年前
&gt; 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.<p>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?
评论 #16126004 未加载