周一，10 月 15 日，从大约 UTC 时间 20:00 开始，crates.io 经历了一次运营事故。您可以在 这里 找到状态页面报告，以及我们关于此事件的推文 这里。

根本原因

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

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

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

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

采取的行动

该用户的 IP 地址立即被封禁。然后，我们将用户的包回溯到过去，以将其从主页中删除。我们还将 cratesio 用户的页面重定向到 404 页面。

最后，cratesio 用户及其上传的所有包都被删除。该用户被举报给 GitHub，并已被 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 或通过 [email protected] 与团队联系。

我们还看到很多沮丧情绪，认为 crates.io 团队没有倾听在官方和非官方 Rust 论坛上提出的担忧。我们同意我们应该改进与社区的沟通，并打算制定更多流程，让大家与我们沟通，以及让团队与整个社区沟通。

背景

社区围绕我们的抢注政策以及我们决定不使用命名空间的决定，一直存在着越来越多的讨论。

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

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

更个案的政策很难做到，并且几乎肯定会导致错误的判断和经常性的争议。

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

我们将讨论是否在发布在我们网站上的政策中包含一些这些信息，这将有助于更多的人了解我们政策背后的理由，而无需团队成员回复每个想要重新审议已经讨论过很长时间的论坛帖子。

结论

我们希望尽快分享发生的事情的细节以及 crates.io 团队为何选择采取行动。我们已经描述的政策变更将在接下来的几个团队会议中进行讨论。在团队有机会进一步讨论之前，一切都没有定论，但我们想分享我们正在讨论的可能变更，以限制对我们计划采取的未来行动的猜测。

提醒一下，如果您想报告与 cratesio 相关的事件，您可以通过 [email protected] 与团队联系。您可以在 https://crates-io.statuspage.io/ 查看服务的状况，也可以关注 Twitter 上的 @cratesiostatus。