Namespacing on Crates.io

Yes, but, it is easier to rate-limit new top-level name-spaces without inconveniencing legitimate users than it is to rate-limit top-level crate names. That’s where I think the win comes from (partially).

Registration of prefixes is a different operation than publishing of a crate, so they could still have different rate limits.

1 Like

Organization name. Re GitHub antispam:

Yes, beyond mere rate limiting, GitHub actively monitors for all sorts of suspicious behavior including spam, and will flag/lock accounts which appear to be doing spammy behaviors. While crates.io could probably benefit from a system (or failing that, exponential backoff rate limiting), GitHub gives it to you for free today, along with many other features.

GitHub already provides all of the functionality for organization membership management, which is ultimately an access control function. From a security perspective, outsourcing this functionality to a "tried and tested" system is much less risky than trying to greenfield it all.

The set of members of any organization is sourced as OAuth users from GitHub, so any system that manages organization membership for crates.io is ultimately building on top of GitHub's user model anyway.

I understand and sympathize with concerns about centralized systems, but crates.io has already gone down that road, and that's unlikely to change any time soon.

Use of GitHub login and ability to give crate ownership to a GitHub Org already gives crates.io this spam protection and user management.

But GitHub is kept one level of abstraction away from crates and their dependencies, so crates-io can add support for other account types, and even migrate off GitHub if that turned out to be necessary.

I think it's possible to retain this property for organizations sourced from GitHub as well

1 Like

I'd consider that a deal-breaker with respect to immutability of crates/name-spaces.

Renaming a GitHub organization does not necessarily require a corresponding change on the crates.io side.

A general suggestion to everyone working out the details of a namespacing proposal – you should create an FAQ in whatever RFC becomes of this. This discussion here is quite long and high-velocity, making is difficult to keep up with all the changing details.

I would guess the most commonly ask questions would involve existing crates with hyphens in their name.

1 Like

A similar idea that would allow other uses to continue publishing using any name they can today is [Pre-RFC]: Packages as Namespaces.

GitHub has already been the IdP for crates.io for several years.

See the third bullet point in this post (where I contrasted using GitHub Organizations vs DNS names):

Sourcing organizations from GitHub as IdP provides organization membership "for free".

Now don't get me wrong, I think domain names are a good option too, and for me they're probably my number two preferred option after GitHub orgs.

The fact that GitHub doesn’t care about names and allows renames means it’s infeasible for cratesio to track names on GitHub. It can perform a one-time copy of the name and then associate GitHub org id with that name.

So:

  1. Register GitHub org “foo”
  2. Register cratesio namespace “foo”
  3. Rename GitHub org “foo” to “bar”
  4. Cratesio can’t handle renames, so it keeps the name “foo”, but still has to allows the “bar” org to manage it. It’d be silly if rename on GitHub locked org out of their packages, and matching by name would be insecure because someone else could rename to “foo”.

And there’s a question whether renamed “bar” org on GitHub is going to be allowed to register “bar” namespace on cratesio. It’s using that name on GitHub, but if it can register more, then that’s one org to many namespaces mapping. If not, then the “bar” they want is impossible to register.

So in the end it seems that the best cratesio can do is to have the same level of indirection between GitHub orgs and namespaces as it has between crates and GitHub orgs: the namespace, like crate, is an independent entity living on cratesio, and GitHub orgs can be added to it to manage it.

Sounds ok to me.

Just for clarity:

In this model, can an individual user be registered as a crates org?


I think it might be useful to create “Corgo” that translates a [package.metadata.org-dependencies] into “real” (git? path?) Cargo dependencies as a proof of concept. It’d be useful to have something to point to and say “hey this scheme actually works”. (If my “pun” name isn’t desired, cargo org or similar works too, ofc.)

To be explicit:

Then, after the first crate publish, would there be any further check of the domain?

I just realized that this could be a one-time check. At first cargo-publish of the crate soc.github.io:utilities, that crate is created on crates-io, iff ownership of soc.github.io is confirmed.

After initial publish, this org key is only used to identify the crate in question, and the accounts with publish permission is handled as it is today. The domain ownership key can even be removed, as its only use was the one-time association.

How do you manage which other users are members of your organization?

So you can add other publishers to the file on the domain, and publishers for a published crate are handled as they are today.

(EDIT: Discourse didn't show this the way I wanted so let's do it manually)

My understanding of your proposal is you’re suggesting crates.io users do the following to register an organization:

  • Register a domain
  • Configure a web server (for the following two items below)
  • Perform AuthN against crates.io via what is effectively X.509 DV
  • Publish organization membership via a file served from the domain (via HTTPS I assume? so they’ll need an X.509 certificate as well)

Regarding your earlier comments above complexity, the above seems relatively complicated to me, especially when the user’s goal is merely “create a crates.io organization and publish a crate”.

Furthermore this provides relatively poor UX, and additional attack surface versus just using the IdP crates.io already uses (i.e. GitHub).

Where GitHub provides a point-and-click experience with strong authentication (e.g. U2F) and active monitoring for suspicious activity, the method you’re describing requires a lot of backend sysadmin work solely for the purposes of authenticating an identity with crates.io.

I would personally prefer the point-and-click experience.

2 Likes

While I'm sure this is all wonderfully intuitive to you, I would not consider that a good user experience for what is fundamentally an access control management tool.

You're also kind of missing the point re: "active monitoring for suspicious activity". The kind of interesting authentication and access change events that GitHub monitors for in its own account system are oblivious to changes you're making in a text file...

1 Like

Docker is an example here. They use namespace for any docker images. So it would be nice if Crates.io does the same thing.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.