GitHub shouldn't be a dependency for publishing Rust on crates.io
infosec.exchange
infosec.exchange
The implementation on this has started.
Something to keep in mind is https://blog.m-ou.se/rust-is-not-a-company/. Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer.
Crates.io and Cargo need namespaces, but the leadership flatly says no.
There's a big problem with name squatting, and nothing is being done about this either.
I get that there are more technically important issues around builds and reproducibility and the like, but this is pretty foundational stuff.
They are favorable to crate-name-as-namespace (so that once you have the tokio crate you can use tokio as a namespace) and there's ongoing work on that. But as said above, it takes work to implement.
There's no desire for other meaning of the word "namespace" because famously nobody ever made a well-reasoned proposal (despite the amount of social media outrage over the lack of namespace).
This isn't a particularly difficult problem, and other package ecosystems have solved it many times in the past.
And on the flip side nobody has ever been able to articulate (that is, not in a hand-wavy fashion) what do those actually bring on the table to make those extra costs worth it.
In a world without namespaces, how does anyone know google-foo belongs to Google?
At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs.
> (what if someone had created an Anthropic user name back in 2016?)
Lol. The world seems to be moving along just fine.
I don't think the problems you list are problems at all.
Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge.
There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$.
It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.
It doesnt. And nobody believes it does. That's the key difference.
> At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs.
In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time.
> Lol. The world seems to be moving along just fine.
You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one?
> There are much bigger problems to worry about than this.
The thing is that mandatory namespaces don't provide meaningful benefit at all.
> It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz.
This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.
https://internals.rust-lang.org/t/survey-of-organizational-o... is a start in just collecting existing knowledge in one place.
That's not true at all. They changed the policy a few years ago to disallow squatting and you can report a package as not doing anything, at which point they'll send the author an email with a deadline to respond, with the plan to remove the crate if there's no change. I actually had this happen firsthand from a package name I had claimed in the early days, forgotten about, and then gotten this email about several months back:
> Jan 29, 2026, 19:25 UTC
> Hi saghm, I'm a member of the crates.io support team, and I'm writing in regards to your pal crate.
> Our policies have changed, and we now disallow crates that have no functionality. The pal crate was reported to us as violating this policy.
> Are you still using this crate name? If so, please reply-all and let us know by February 12, 2026. If we don't hear back from you by that date, we will be removing this crate.
> The rest of your crates are fine and will NOT be removed.
(I responded back immediately to confirm I wasn't using the crate and hadn't been aware of the policy change, so they could take action immediately without needing to wait until the deadline)
And you forgot to mention the bureaucratic process that also blocks warm bodies from developing code because the changes are not/unlikely to be accepted regardless of the level of excitement
Ironically hosted on GitHub.
https://www.youtube.com/watch?v=zGS-HqcAvA4 Here's a long video from jon gjengset that shows how it works and some of the effort already done to de-couple from github.
Crates is widely used so it's a rebuilding the track while the train is driving kind of problem.
It's just not a priority for the project right now, but I would also definitely like to see the issue done. It might be good for the rust project to vote on things like this during surveys so they know where to focus work!
TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.
https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
Obviously, the situation has changed in recent years, so it's now considered a much higher priority by many people and some of them are actively working on it. But it's a lot of work to be done by volunteers, so it takes time.
That's the reality of open-source projects: things get done when they are important enough to motivate someone to either fund it or work on in their free time, not according to idyllic roadmaps and schedules.
10 (edit: 8) years ago MS took over Github. The writing was on the wall then...
No need to explain OSS to me, I maintain and contribute.
The reason LLMs seem to like them is because humans liked them first.
While this might have been true in rust-circles (which I'm an outsider to), I think this varied a lot in different circles. Most free software projects invested a lot of money, time and effort in setting up better (for themselves) alternatives to Github.
Everything from videolan and GNU Savannah to XDG, Gnome, KDE, etc.
aren't they like some kind of non-profit (in the legal sense) that is still able to take a lot of money (from players like Google and Co, to justify fixing this), as opposed to ... say the Zig foundation, ... that is is also "non-profit" but can't get money the same way?
Cargo also makes vendoring dependencies trivial.
I've worked on projects where we vendored all third-party crates, for example, so our config just pointed to that vendoring, and I think support ought to be better these days…
You can:
- host a private index
- host the proprietary binaries in a git repo and use a git dependency
- commit the proprietary binaries into your source repo, and use a path dependency
For example, I could push some malicious code, tag it, wait for Packagist to finish pulling it to publish a package, and then amend history to remove the malicious code, rewrite the git-tag, and force-push both to the git server.
This scheme makes it hard/impossible to push mismatching code by accident, but doesn't do much to stop a malicious actor.
Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.
Also supports npm, PyPI, and Ansible Galaxy.
The gripe with using GitHub auth for crates.io is that GitHub is owned by a large, fickle corporation with a (shall we say) complicated history with open source, and people object on principled grounds to being forced to use GitHub in order to participate in the crates.io ecosystem.
It's really not clear to me why people keep avoiding that.
2) Note expired domains and register them yourself.
3) Supply chain compromise.
That, and not wanting people to fork out money for a domain as a requirement to participate in the ecosystem.
I know this kind of money sounds banal for us now, but even I, when I was a student (especially in high school), tried to avoid spending any money on my hobby (programming).