Namespacing on Crates.io

[kornel]

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

[bascule]

If by name, you mean user name, we’d still have that, no?

Organization name. Re GitHub antispam:

Does it really?

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.

Why make crates.io dependent on other commercial services to that degree? I’m having trouble understanding why that is a good thing long-term?

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.

[kornel]

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.

[bascule]

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

[gbutler]

Note that GitHub allows renaming of orgs/username

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

[bascule]

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.

[eminence]

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.

[soc]

I’ll once again throw out the idea of using GitHub organizations:

The minute you do this, people will start complaining and (rightfully) demand that other IdP are also accepted.

So your system would turn from

cratename // global namespace

to

somegithuborg-cratename // your proposal

to

someotheridp-someorgatthatidp-cratename

in no time.

When we have arrived at that … what’s exactly the difference to doing the simple, obvious thing … and using domain names from the start?

the third issue is the big one for me. Using anything but GitHub for this purpose will involve building a complicated organization membership management system into crates.io

I think it’s not that onerous to send a HTTP GET request to some host and check the reply.

[ethanpailes]

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

[bascule]

The minute you do this, people will start complaining and (rightfully) demand that other IdP are also accepted.

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

what’s exactly the difference to doing the simple, obvious thing … and using domain names from the start?

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

Namespacing on Crates.io

I’ll once again throw out the idea of using GitHub organizations: outsources name registry to another system outsources antispam to another system outsources organization membership to the system which is already the IdP. In for a penny, in for a pound Domain names buy you the first two, but given the existing GitHub IdP integration, the third issue is the big one for me. Using anything but GitHub for this purpose will involve building a complicated organization membership management system …

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.

[kornel]

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.

[bascule]

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.

[CAD97]

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.)

[soc]

This seems all to be extremely over-complicated, especially compared to the domain-based approach:

Basic task: I want to publish my dirs crate under the soc.github.io.

1. I add organization = "soc.github.io" to my Cargo.toml.
2. I run cargo publish.
3. The command prints the following text to the console:

   Crates.io couldn’t verify that you own soc.github.ui. To prove ownership, place a file named “domain-owner” with the following text at your domain root: ZG2ioiTY3tMgwDYfmb6p

4. I place the file “domain-owner” with the randomly generated string at `soc.github.io/domain-owner.
5. I rerun cargo publish. crates.io checks that the string matches and publishes the crate under the namespace.

That’s it. Super simple. No dependency on any specific service, no fancy IdP stuff, no “how to organize organizations” problems. Everything keeps working exactly as it is now – the setup is even simpler than cargo login.

[CAD97]

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.

[soc]

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

Yes.

I would check it on every cargo publish to make changes in domain ownership both seamless and very obvious.

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.

Exactly!

Also, tying each random string to a specific user account means that in projects where different developers work on different crates, each developer could have publish rights only for his own projects.

And individual permissions to publish under some domain could easily be granted or revoked (by adding/removing that developers’ generated random text string in the domain-owner file).

[bascule]

That’s it. Super simple. No dependency on any specific service, no fancy IdP stuff, no “how to organize organizations” problems. Everything keeps working exactly as it is now – the setup is even simpler than cargo login .

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

[CAD97]

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

And individual permissions to publish under some domain could easily be granted or revoked (by adding/removing that developers’ generated random text string in the domain-owner file).

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)

[soc]

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

“is a member of an organization” == “can publish to a domain” == “has an entry in the domain-owner file”

[bascule]

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.