Rust RFC #3243, which implements optional namespace support for Rust, has been approved1 and merged. It is now official Rust project policy, and I’m looking forward to using it.

From the perspective of actually getting to use it, though, it’s maybe more the end of the beginning.

Implementing this on crates.io2 will require code changes, so isn’t going to be immediate. There’s nothing there that strikes me as particularly problematic from an implementation perspective: crate search will presumably need some tweaking, we’ll have to figure out if this changes how we rate limit crate publication, and the inherited ownership semantics in the RFC — while likely sufficient for the initial, single level implementations — will probably eventually need more refinement to handle less common scenarios.3

Policy

crates.io policy, however, is an area that will need more work.

Owners of existing crates will likely be largely unaffected here. To use serde as an example, there are already a handful of existing serde_* crates. This RFC will provide the option to migrate to serde::*, and will (at the very least) prevent others from publishing crates within that namespace.

I fear, though, that there will be a landrush of users who want to grab good namespaces for their own use.

In some cases, this will simply be spam, and can be dealt with accordingly per crates.io policy.

Some may be attempts at typosquatting, although top level crate owners controlling their namespaces means that there aren’t any new opportunities here. (For example, were someone to want to namespace a hypothetical serde::json crate, they could try serd::json4, but serde::json2 wouldn’t be an option.) Also, we’re pretty vigilant on this now, and I won’t be comfortable with crates.io accepting namespaced crates until we know the existing typosquatting checks5 are extended to handle them appropriately.

Finally, I suspect the crates.io team will have to field more requests based on trademark and other intellectual property rights. These are going to be time-consuming and potentially expensive6 to deal with, not to mention the issues that will be caused if a commonly used crate has to be removed or renamed, since much of the Rust ecosystem assumes an immutable crates.io index.

Verification

I also think we’re going to have to figure out a story around namespace verification over time. Put simply, this would give us a way of saying that the northwind-traders namespace belongs to the actual Northwind Traders company, and indicating that somehow in the crates.io UI.

This already exists in Java’s Maven Central7 and .NET’s NuGet8, and the research9 I did for my What’s in a Namespace talk last year at PackagingCon suggests that good top level namespace verification policies discourage typosquatting attacks, presumably because users have been trained to expect some sort of signal in their registry that the package is authentic10.

To me, it makes sense that we should provide a way of saying that a namespace prefix is reserved (or owned, or verified, or whatever word you’d like to use) by the entity that you’d expect. I think this need would increase significantly if multi-level namespaces11 are ultimately provided, but I think it will still exist even today.

Maybe there’s a world in which signing completely solves this (BigCorp signs a key for ProductTeam, who uses that key to sign their crates, and then crates.io has some way of displaying that chain of trust), but that feels a long way off.

Doom and gloom?

All that said, though, I really don’t think this is a bad thing. (No matter what the last few paragraphs suggest.)

Namespacing is a new thing for Rust, and it’s going to bring new challenges (for other teams as well, I’m sure), but we’re not treading completely new ground here, and none of these issues are critical, day zero things. They’re just going to require careful thinking and planning.

I’m looking forward to us figuring them out together.

  1. The observant reader might note that I didn’t approve the RFC as part of the crates.io FCP review. I’m generally supportive of the aims of the RFC, but wasn’t 100% sold on some of the detail — not enough to derail a process that had taken literal years of effort from multiple very smart people to get to that point, but enough that I didn’t feel totally comfortable approving it.

    I may eventually write up what would have been my objections, but they’re irrelevant to this blog post. ↩

  2. Author disclosure statement: I’m a member of the crates.io team, although probably not the member of the crates.io team that will implement most of this. I’m also employed by the Rust Foundation to work on ecosystem security, which (unsurprisingly) overlaps significantly with crates.io. ↩

  3. One initial thought I have here is that I’m not sure conflating the permission to curate a namespace with the ability to publish to a crate within a namespace is the right thing to do in all cases, but this is something that can be iterated on later. ↩

  4. I mean, they actually couldn’t, because I picked that example carefully, but you get the general idea. ↩

  5. Inside Rust blog post on this coming to a blog near you Real Soon Now™. (I should probably be finishing that now instead of writing this.) ↩

  6. The crates.io team has policies that nominally address requests for crates based on IP, but ultimately these may have to go through the Rust Foundation’s legal counsel, which isn’t free, and the Foundation’s budget isn’t limitless. ↩

  7. Maven Central’s verification system is based on domain names, which isn’t something we can adopt wholesale for multiple reasons — the lack of multi-level namespaces in the RFC that was accepted, along with there being existing crates that are also TLDs — but it might make sense as part of a larger verification process. (Maven Central also requires verification for new namespaces, which is unlikely to be something we’d ever want in Rust.) ↩

  8. The exact criteria used by NuGet are opaque, but that’s obviously intentional. Unfortunately, we’d probably have to do something similar for crates.io, since we can’t just use DNS as a source of identity proof.7 ↩

  9. I don’t exactly have p-values for this stuff, because it was research for a 25 minute conference talk and we don’t exactly have a large sample size for major language ecosystems. I’m comfortable saying this, but I’m also happy to admit that this is at about a “trust me, bro” level of reproducibility. ↩

  10. This is obviously separate from giving crate authors the ability to sign their crates, which is another way of attesting provenance. While we’re not planning on addressing this at the Rust Foundation until after infrastructure-level concerns are dealt with, there are others already thinking about this, both on Zulip and elsewhere. ↩

  11. My assumption here is that the single level namespaces approved in this RFC will tend to be used at a business unit level in larger companies: since company::product::client isn’t an option, I’d expect we’ll see product::client, for the most part. Should namespaces be opened up to multiple levels later, this may no longer hold. ↩