在 10 月 15 日星期一，大约从 UTC 时间 20:00 开始，crates.io 发生了运营事件。您可以在此处找到状态页面报告，以及我们关于此事的推文此处。

根本原因

一个名为 cratesio 的用户在 crates.io 上创建，并开始使用常见、简短的名称上传软件包。这些软件包除了一个 Cargo.toml 文件和一个 README.md 文件之外没有其他内容，该 README.md 文件指示用户如果他们想要使用该名称，则应该在 crates.io 问题跟踪器上打开一个 issue。

该用户上传软件包的速度最终导致我们的服务器被 GitHub 限速，导致所有软件包上传或撤回速度减慢。不涉及更新索引的端点未受影响。

我们决定对这种行为采取行动，因为

• 上传的软件包的内容似乎是在试图冒充 crates.io 团队（通过用户名 cratesio 以及在软件包的 Readme 文件中引导人们到 crates-io 问题跟踪器）
• 上传速度影响了服务的稳定性

采取的行动

该用户的 IP 地址被立即禁止。然后我们回溯了该用户的软件包，将它们的软件包从主页上删除。我们还将 cratesio 用户的页面重定向到 404。

最后，cratesio 用户及其上传的所有软件包都被删除。该用户已向 GitHub 举报，此后被他们禁止。

事件时间线

• UTC 时间 20:09：GitHub 用户 cratesio 注册了一个帐户
• UTC 时间 20:13：该用户开始以大约每 2 秒一个软件包的速度上传软件包
• UTC 时间 20:17：所有更新索引的请求开始耗时 10 秒以上
• UTC 时间 20:41：发送电子邮件给 Rust 审核团队，报告该用户
• UTC 时间 20:46：该报告被转发给 crates.io 团队
• UTC 时间 20:50：该用户在 crates.io 团队 Discord 中被举报。
• UTC 时间 21:00：该用户的 IP 地址被阻止访问该网站
• UTC 时间 21:20：该用户的软件包已从 crates.io 主页删除
• UTC 时间 21:20：该事件在 status.crates.io 上发布
• UTC 时间 22:49：该用户在 crates.io 上的帐户页面被删除。
• UTC 时间 23:58：软件包、所有关联数据以及用户的帐户都从 crates.io 中删除
• UTC 时间 00:40：软件包已从索引中删除。

未来措施

单个用户或 IP 地址不应该在短时间内上传那么多软件包。我们将在此端点上引入速率限制，以限制脚本未来能够上传的软件包数量。

我们还在研究禁止使用可能冒充官方 Rust 团队的用户名。我们将更新我们的政策，明确说明不允许这种形式的冒充。我们将在未来几周内确定此政策的确切措辞。

虽然不可能知道用户的意图，但包括团队在内的许多人猜测，此行为要么与最近社区对 crates.io 政策（特别是抢注政策）的挫败感加剧有关，要么直接相关。

无论此事件是否具有此意图，cratesio 团队都想重申，采取类似我们周二经历的那种行动不是参与有关 crates.io 政策对话的适当且有效的方式。我们将添加一项政策，明确说明试图扰乱 crates.io 以表达或进一步阐明观点是不恰当的，并将被视为恶意攻击。我们将在未来几周内确定此政策的确切措辞。

如果您认为某项政策存在问题，提出更改的正确方法是创建 RFC 或通过 help@crates.io 发送消息给团队。

我们还看到很多人对 crates.io 团队没有听取官方和非官方 Rust 论坛上提出的担忧感到沮丧。我们同意我们应该改进与社区的沟通，并打算开发更多的流程，让人们与我们沟通，以及让团队与普通社区沟通。

背景

社区中围绕我们的抢注政策和我们不使用命名空间的决定进行了越来越多的讨论。

最初的抢注政策于 2014 年发布，其中包含比我们网站上当前内容更多的关于该政策背后的理由的信息。原始政策的全文是

没有人喜欢“抢注者”，但找到可以机械应用来定义抢注的好规则是出了名的困难。如果我们要求软件包至少有一些内容，那么抢注者会插入随机内容。如果我们要求定期更新，那么抢注者会确保定期更新，而该规则可能会对相对稳定的软件包过于严格。

更具个案性的政策将很难做到正确，并且几乎肯定会导致严重的错误和频繁的争议。

相反，我们将坚持先到先得的系统。如果有人想接管一个软件包，并且先前的所有者同意，则现有维护者可以将他们添加为所有者，并且新维护者可以删除他们。如有必要，团队可能会联系不活跃的维护者，并协助调解所有权转让过程。我们知道，这在实践中意味着某些理想的名称会在早期被占用，并且那些早期用户可能不会以最佳方式使用它们（无论它们是被抢注者声明还是仅仅是低质量的软件包）。其他生态系统通过使用更丰富多彩的名称来解决这个问题，我们认为这实际上是该系统的一个功能，而不是一个错误。我们在下面对此进行了更多讨论。

我们将讨论是否将其中一些信息包含在我们网站上发布的政策中，是否可以帮助更多人理解我们政策背后的理由，而无需团队成员回复每一个想要重新讨论已经详细讨论过的问题的论坛帖子。

结论

我们想分享发生的事情的详细信息以及 crates.io 团队选择尽快采取行动的原因。我们描述的政策更改将在接下来的几次团队会议中讨论。在团队有机会进一步讨论之前，一切都不是一成不变的，但是我们想分享我们正在讨论的可能更改，以限制人们对我们计划采取的未来行动的猜测。

提醒一下，如果您想报告有关 cratesio 的事件，可以通过 help@crates.io 发送消息给团队。您可以在 https://crates-io.statuspage.io/ 和/或在 Twitter 上关注 @cratesiostatus 来查看服务状态。