Namespacing on Crates.io

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

[soc]

the method you’re describing requires a lot of backend sysadmin

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

The approach I described takes literally 3 seconds using your own preferred “IdP”:

As you see, it comes with “a point-and-click experience with strong authentication (e.g. U2F) and active monitoring for suspicious activity”.

The difference with this approach is that developers can make their own decisions and pick whatever proprietary “IdP” they prefer, including none at all (and use their own domain).

[bascule]

As you see, it comes with “a point-and-click experience with strong authentication (e.g. U2F) and active monitoring for suspicious activity”.

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…

[soc]

At the point were a malicious user has circumvented “active monitoring for suspicious activity” to log into a victim’s account you are in pretty bad shape security-wise anyway.