Yes this is a problem in Rust-land too. crates.io doesn't support user tokens to be limited to a crate only [1], but gives access to all the crates an user has access to. So if the token leaks, attackers have access to all your crates. For the cpal crate we worked around the issue by creating a new github user that has only access to the cpal crate (and maybe in the future a few other crates in the same org) but nothing more [2]. This solution isn't really good tho.
[1]: https://github.com/rust-lang/crates.io/issues/849
[2]: https://github.com/RustAudio/cpal/pull/337
In Publish NPM Package with GitHub Actionsrust-lang
crates.io
Rust2014–2026
rust-lang / crates.io
crates.io
The Rust package registry
30Distinct people
39Mentions
1Explicit recommenders
3.8KGitHub stars
What to know before exploring
What it is
The Rust package registry
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
PS: I love that Mozilla uses Rust for the media-parser to boost security. But in the context of wider system engineering, there's a danger that crates.io will become another…
DyslexicAtheist used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year39 dated mentions
Observed mentions: 2014-11-20 20:55:27 UTC to 2026-10-26 08:22:53 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 8 | 2 | 6 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Homepage
| Usage Policy
| Security
| Status
| Contact
| Contributing
🦀 Overview
Welcome to the GitHub repository for crates.io, the official package registry for the Rust programming language.
crates.io serves as a central registry for sharing "crates", which are packages or libraries written in Rust that you can use to enhance your projects. This repository contains the source code and infrastructure for the crates.io website, including both frontend and backend components.
This service is maintained for you by the crates.io team, with support from the Rust Foundation. File hosting is donated by Amazon Web Services, with CDN services donated by Fastly.
🛠️ Contributing
We welcome contributions from the community! Whether you're fixing a bug, implementing a new feature, or improving documentation, your contributions help make crates.io better for everyone.
crates.io is built with Rust for the backend services. More specifically, the axum web framework and diesel for database access, with a custom-built background worker system. The frontend is a SvelteKit application written in TypeScript.
Please review our contribution guidelines before submitting your pull request. The same document also contains instructions on how to set up a local development environment, with additional structured documentation available in AGENTS.md.
🪲 Issue Tracker
If you encounter any bugs or have technical issues with crates.io, please feel free to open an issue in our issue tracker. Our team will review and address these as fast as we can.
For feature suggestions, enhancements, or general discussions about crates.io, we encourage you to utilize GitHub Discussions instead. Visit the Discussions tab to engage with the community, share your ideas, and participate in ongoing conversations. Your input is valuable in shaping the future of crates.io, and we look forward to hearing your thoughts!
☎️ Contact
For any questions or inquiries about crates.io, feel free to reach out to us via:
Zulip: #t-crates-io
Email: help@crates.io
GitHub Discussions: rust-lang/crates.io
We're here to help and eager to hear from you!
🤗 Code of Conduct
Respect and inclusivity are core values of the Rust community. Our Code of Conduct outlines the standards of behavior expected from all participants. By adhering to these guidelines, we aim to create a welcoming space where individuals from diverse backgrounds can collaborate and learn from one another. We appreciate your commitment to upholding these principles and fostering a positive community atmosphere.
If you have a Code of Conduct concern, please contact the moderators using the links in the Code of Conduct.
⚖️ License
Licensed under either of these:
Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
Read the full README on GitHubWhat Hacker News says
4 sourcesI'm guessing they are talking about this issue which has been open for a disturbingly long time: https://github.com/rust-lang/crates.io/issues/955
In Candidates for Mozilla's IRC SuccessorI've used Rust a bit, but not enough to know the details of how cargo and crates.io approach managing collected information.
There seems to be an open issue and WIP PR with more details:
Issue: https://github.com/rust-lang/crates.io/issues/955
PR: https://github.com/rust-lang/www.rust-lang.org/pull/919/file...
The cargo manifest also supports things like:
The publish field (optional)
The publish field can be used to prevent a package from
being published to a package registry (like crates.io) by mistake,
for instance to keep a package private in a company.
[package]
# ...
publish = false
But I would be curious if someone more knowledgeable than myself would be interested in giving a quick summary of the approach?
In Go 1.13 Release NotesI'd agree, but I don't think the additional complexity is worth it. I was prepared to suggest stuff like company.com/
That said, it's worked well for golang as far as I can see, despite 99% of the packages are github.com/<creator>/<package>.
Here are some writeups on what the rust team decided:
- https://github.com/rust-lang/crates.io/issues/58
- https://internals.rust-lang.org/t/crates-io-package-policies...
Their stance seems pretty reasonable though I'm not sure I would have done the same (and it's obviously very likely I would be wrong to do the opposite of what they did):
> Namespacing
> In the first month with crates.io 58, a number of people have asked us aboutthe possibility of introducing namespaced packages 90.
> While namespaced packages allow multiple authors to use a single, generic name, they add complexity to how packaged a
Read the rest
re referenced in Rust code and in human communication about packages. At first glance, they allow multiple authors to claim names like http, but that simply means that people will need to refer to those packages as wycats' http or reem's http, offering little benefit over package names like wycats-http or reem-http.
> When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. And we’ve seen the success of several 10,000+ package ecosystems like NPM and RubyGems whose communities are prospering within a single namespace.
> In short, we don’t think the Cargo ecosystem would be better off if Piston chose a name like bvssvni/game-engine (allowing other users to choose wycats/game-engine) instead of simply piston.
> Because namespaces are strictly more complicated in a number of ways,and because they can be added compatibly in the future should they become necessary, we’re going to stick with a single shared namespace.