惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
S
Schneier on Security
C
Cyber Attacks, Cyber Crime and Cyber Security
N
News and Events Feed by Topic
TaoSecurity Blog
TaoSecurity Blog
T
Threat Research - Cisco Blogs
博客园 - 三生石上(FineUI控件)
大猫的无限游戏
大猫的无限游戏
The Last Watchdog
The Last Watchdog
Latest news
Latest news
AI
AI
Webroot Blog
Webroot Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
The Hacker News
The Hacker News
Google DeepMind News
Google DeepMind News
S
Securelist
IT之家
IT之家
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
P
Proofpoint News Feed
Last Week in AI
Last Week in AI
博客园 - Franky
美团技术团队
Cyberwarzone
Cyberwarzone
C
CERT Recently Published Vulnerability Notes
Security Archives - TechRepublic
Security Archives - TechRepublic
Security Latest
Security Latest
T
Tailwind CSS Blog
S
Security Affairs
S
Security @ Cisco Blogs
H
Heimdal Security Blog
腾讯CDC
N
News | PayPal Newsroom
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
博客园 - 司徒正美
博客园_首页
Jina AI
Jina AI
M
MIT News - Artificial intelligence
Hacker News - Newest:
Hacker News - Newest: "LLM"
B
Blog
F
Full Disclosure
www.infosecurity-magazine.com
www.infosecurity-magazine.com
T
The Blog of Author Tim Ferriss
Schneier on Security
Schneier on Security
N
News and Events Feed by Topic
NISL@THU
NISL@THU
C
Cisco Blogs
T
Troy Hunt's Blog
O
OpenAI News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

Rust Blog

Security Advisory for Cargo (CVE-2026-5223) | Rust Blog Security Advisory for Cargo (CVE-2026-5222) | Rust Blog Project goals update — April 2026 (end of 2025H2) | Rust Blog Rust is participating in Outreachy | Rust Blog Raising the baseline for the `nvptx64-nvidia-cuda` target | Rust Blog Announcing Google Summer of Code 2026 selected projects | Rust Blog Announcing Rust 1.95.0 | Rust Blog docs.rs: building fewer targets by default | Rust Blog Changes to WebAssembly targets and handling undefined symbols | Rust Blog Announcing Rust 1.94.1 | Rust Blog Security advisory for Cargo | Rust Blog What we heard about Rust's challenges | Rust Blog Call for Testing: Build Dir Layout v2 | Rust Blog Announcing rustup 1.29.0 | Rust Blog Announcing Rust 1.94.0 | Rust Blog 2025 State of Rust Survey Results | Rust Blog Rust debugging survey 2026 | Rust Blog Announcing Rust 1.29.2 Announcing Rust 1.29 Launching the 2018 State of Rust Survey Announcing Rust 1.28 What is Rust 2018? Announcing Rust 1.27.2 Announcing Rust 1.27.1 Security Advisory for rustdoc Announcing Rust 1.27 Announcing Rust 1.26.2 Announcing Rust 1.26.1 Rust turns three Announcing Rust 1.26 The Rust Team All Hands in Berlin: a Recap Increasing Rust’s Reach 2018 Announcing Rust 1.25 Rust's 2018 roadmap Announcing Rust 1.24.1 Announcing Rust 1.24 The 2018 Rust Event Lineup Announcing Rust 1.23 New Year's Rust: A Call for Community Blogposts Rust in 2017: what we achieved Announcing Rust 1.22 (and 1.22.1) Fearless Concurrency in Firefox Quantum Announcing Rust 1.21 impl Future for Rust Rust 2017 Survey Results Announcing Rust 1.20 Announcing Rust 1.19 The 2017 Rust Conference Lineup Rust's 2017 roadmap, six months in Increasing Rust’s Reach Announcing Rust 1.18 Two years of Rust The Rust Libz Blitz Launching the 2017 State of Rust Survey Announcing Rust 1.17 Announcing Rust 1.16 Rust's language ergonomics initiative Announcing Rust 1.15.1 Rust's 2017 roadmap Announcing Rust 1.15 Announcing Rust 1.14 Announcing the First Underhanded Rust Contest Announcing Rust 1.13 Announcing Rust 1.12.1 Announcing Rust 1.12 Incremental Compilation Announcing Rust 1.11 Shape of errors to come The 2016 Rust Conference Lineup Announcing Rust 1.10 State of Rust Survey 2016 Announcing Rust 1.9 One year of Rust Taking Rust everywhere with rustup Launching the 2016 State of Rust Survey Cargo: predictable dependency management Introducing MIR Announcing Rust 1.8 Announcing Rust 1.7 Announcing Rust 1.6 Announcing Rust 1.5 Announcing Rust 1.4 Announcing Rust 1.3 Rust in 2016 Announcing Rust 1.2 Rust 1.1 stable, the Community Subteam, and RustCamp Announcing Rust 1.0 Abstraction without overhead: traits in Rust Rust Once, Run Everywhere Mixing matching, mutation, and moves in Rust Fearless Concurrency with Rust Announcing Rust 1.0 Beta Announcing Rust 1.0.0.alpha.2 Rust 1.0: status report and final timeline Announcing Rust 1.0 Alpha Rust 1.0: Scheduling the trains Yehuda Katz and Steve Klabnik are joining the Rust Core Team Cargo: Rust's community crate host Stability as a Deliverable Road to Rust 1.0
Update on the October 15, 2018 incident on crates.io
The Crates.io Team · 2018-10-19 · via Rust Blog

On Monday, Oct 15, starting at approximately 20:00 UTC, crates.io sustained an operational incident. You can find the status page report here and our tweets about it here.

Root Cause

A user called cratesio was created on crates.io and proceeded to upload packages using common, short names. These packages contained nothing beyond a Cargo.toml file and a README.md instructing users that if they wanted to use the name, they should open an issue on the crates.io issue tracker.

The rate at which this user uploaded packages eventually resulted in our servers being throttled by GitHub, causing a slowdown in all package uploads or yanks. Endpoints which did not involve updating the index were unaffected.

We decided to take action on this behavior because:

  • The contents of the uploaded packages appeared to be an attempt to impersonate the crates.io team (both through the username cratesio, as well as directing people to the crates-io issue tracker in the crates' Readme files)
  • the rate of uploading impacted the stability of the service

Action Taken

The user's IP address was banned immediately. We then backdated the users' packages to remove their packages from the homepage. We also redirected the cratesio user's page to a 404.

Finally, the cratesio user and all crates they uploaded were deleted. The user was reported to GitHub, and has since been banned by them.

Timeline of events

  • 20:09 UTC: The GitHub user cratesio registers an account
  • 20:13 UTC: This user begins uploading packages at a rate of roughly one package every 2 seconds
  • 20:17 UTC: All requests updating the index begin to take 10+ seconds
  • 20:41 UTC: An email is sent to the Rust moderation team reporting this user
  • 20:46 UTC: The report is forwarded to the crates.io team
  • 20:50 UTC: The user is reported in the crates.io team Discord.
  • 21:00 UTC: The user's IP address is blocked from accessing the site
  • 21:20 UTC: The user's packages were removed from the crates.io homepage
  • 21:20 UTC: The incident is announced on status.crates.io
  • 22:49 UTC: The user's account page on crates.io is removed.
  • 23:58 UTC: The packages, all associated data, and the user's account are deleted from crates.io
  • 00:40 UTC: The packages are removed from the index.

Future measures

It should not have been possible for a single user or IP address to upload that many packages in a short period of time. We will be introducing rate limiting on this endpoint to limit the number of packages a script is able to upload in the future.

We are also looking into disallowing usernames that could be impersonating official Rust teams. We will be updating our policies to clearly state that this form of impersonation is not allowed. We will be deciding the exact wording of this policy in the coming weeks.

While it is impossible to tell a user's intent, many, including the team, have speculated that this action was either associated with or directly related to the recent escalation in community frustration around crates.io policies, in particular, the squatting policy.

Regardless of whether this incident had this intent, the cratesio team would like to reiterate that taking actions such as the one we experienced on Tuesday is not an appropriate nor effective way to contribute to dialogue about crates.io policy. We will be adding a policy making it clear that attempting to disrupt crates.io in order to make or further a point is not appropriate and will be considered a malicious attack. We will be deciding on the exact wording of this policy in the coming weeks.

If you feel that a policy is problematic, the correct place to propose a change is by creating an RFC or messaging the team at help@crates.io.

We also have seen a lot of frustration that the crates.io team is not listening to the concerns that are being raised on both official and unofficial Rust forums. We agree that we should improve our communication with the community and intend to develop more processes for folks to communicate with us, as well as for the team to communicate to the general community.

Background

There has been a growing amount of discussion in the community around our squatting policy and our decision not to have namespacing.

The original squatting policy, published in 2014, contains a lot more information about the rationale behind the policy than what is currently on our website. The full text of the original policy is:

Nobody likes a “squatter”, but finding good rules that define squatting that can be applied mechanically is notoriously difficult. If we require that the package has at least some content in it, squatters will insert random content. If we require regular updates, squatters will make sure to update regularly, and that rule might apply over-zealously to packages that are relatively stable.

A more case-by-case policy would be very hard to get right, and would almost certainly result in bad mistakes and regular controversies.

Instead, we are going to stick to a first-come, first-served system. If someone wants to take over a package, and the previous owner agrees, the existing maintainer can add them as an owner, and the new maintainer can remove them. If necessary, the team may reach out to inactive maintainers and help mediate the process of ownership transfer. We know that this means, in practice, that certain desirable names will be taken early on, and that those early users may not be using them in the most optimal way (whether they are claimed by squatters or just low-quality packages). Other ecosystems have addressed this problem through the use of more colorful names, and we think that this is actually a feature, not a bug, of this system. We talk about this more below.

We will be discussing whether including some of this information in the policy published on our website would help more people to understand the rationale behind our policy, without requiring members of the team to reply to every forum thread wanting to re-litigate what has already been discussed at length.

Conclusion

We wanted to share the details of what happened and why the crates.io team chose to take action as quickly as possible. The policy changes we've described will be discussed during the next several team meetings. Nothing is set in stone until the team has a chance to discuss them further, but we wanted to share the possible changes we're discussing to limit speculation on what future actions we're planning on taking.

As a reminder, if you would like to report an incident regarding cratesio, you can message the team at help@crates.io. You can view the status of the service at https://crates-io.statuspage.io/ and/or by following @cratesiostatus on Twitter.