Allow restricting API token to publish a subset of crates

[Nemo157]

Now that #688 is available, it would be great to be able to generate a token that is only able to publish a single/limited subset of crates. (A subset to account for things like proc-macro crates commonly being published as a pair of relatively tightly coupled crates).

I'm not sure exactly where the UI for creating these tokens should go, one idea I have had so far:

• In the "New Token" row on the "Account Settings" page add a little expander with text like "Limit Token Access", expanding that can show a list of all crates with checkboxes for selecting which to be able to publish to.

I feel that would not be great for a user that has access to many many crates though.

Alternative idea I had was to somehow do it via the crate page instead. I don't see any nice to allow adding additional crates to the token that doesn't basically end up with a massive list like above.

---

Probably worth doing a survey of if any other package repositories support something similar. Closest parallel I can think of is GitHub repository scoped API tokens, but as far as I'm aware they don't allow for accessing a selection of repositories; you either have a token that can access all repositories you have access to, or a token that can access a single repository. I'll try and take a look soon and update here.

[sfackler]

This would be fantastic for things like publishing automatically in CI builds.

[est31]

There is a workaround for this issue which we applied in RustAudio/cpal#337 :

1. you create a new github user, e.g. reponame-publish-bot
2. you create a new github team that both you as well as reponame-publish-bot are members of.
3. that team is given access to the crates.io crate(s) you want the scope to apply to

The crates.io token of the reponame-publish-bot account is now scoped to the set of crates you gave access to. Due to step 2, an attacker gaining access to the token can't remove anyone as owners or add any new owners.

[smarnach]

@est31 While this approach works, the GitHub terms don't allow more than one free account per individual person, so we can't really make this an official recommendation. Eventually we will need a better permissions model.

[est31]

GitHub terms don't allow more than one free account per individual person

I didn't know about that rule but looking it up, it exempts machine accounts:

https://help.github.com/en/github/site-policy/github-terms-of-service#3-account-requirements

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine)

Anyways, I do agree with you that this issue shouldn't be closed or ignored because the workaround exists. There should be a proper feature for it right in crates.io.

[est31]

Also note that you may only have up to one free machine account (same sections of Github terms as linked above):

A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free User Account.

So this limits the number of gratis crates.io tokens per person to 2.

[pietroalbini]

I'm willing to do the backend work to implement this, and @locks should be available to then hook the changes in the frontend. What I'd like to implement here is two things: endpoint scopes to limit which things a crate can do, and crate scopes to limit which crates the token is allowed to act on.

A mockup of the UI I'd love to see is:

Endpoint scopes

During token creation the user will be allowed to choose whether to allow the token access to all the API endpoints (the current behavior) or to select which permissions the token has.

The initial set of scopes will cover all endpoints accessible through cargo:

• publish: allow publishing new crates and new versions of crates you own
• yank: allow yanking and unyanking crates
• owners: allow inviting new owners to the crate, removing existing owners and allow accepting invitations

New scopes might be added in the future to cover more API endpoints. All existing tokens will default to allowing access to all the API endpoints, to maintain backward compatibility.

Note that once we define the set of endpoints a token is allowed to create adding more endpoints to them might be considered a breaking change for existing tokens, as we would allow the token to do things the owner might not want.

The set of endpoints covered by the initial set of scopes is:

Endpoint	Required scope
PUT /crates/new	publish
DELETE /crates/:crate_id/:version/yank	yank
PUT /crates/:crate_id/:version/unyank	yank
PUT /crates/:crate_id/owners	owners
DELETE /crates/:crate_id/owners	owners
GET /me/crate_owner_invitations	owners
PUT /me/crate_owner_invitations/:crate_id	owners
PUT /me/crate_owner_invitations/accept/:token	owners

Crate scopes

During token creation the user will be allowed to choose whether to allow the token access to all the crates they own or just a subset of them. This setting will only apply to endpoints handling crates: other endpoints will continue to work even with crate-scoped tokens.

To select which crates the token is allowed to operate on the user will have to insert a pattern we will match on every request. The pattern will be a simplified regex, only allowing | to include multiple patterns and * to include any character. Example of such patterns include:

• lazy_static|regex: allow acting on both the lazy_static and regex crates
• serde|serde-*: allow acting on serde and any crate starting with serde-
• rustc-ap-*: allow acting on all the crates starting with rustc-ap-

I think this approach is better that letting the user tick checkboxes for each crate they want to allow. Checkboxes benefit accounts with a small amount of crates, while the pattern benefits large projects with tons of crates, and I believe big projects are the ones more likely to scope down which crates a token is allowed to access.

All existing tokens will allow access to any crate, to maintain backward compatibility.

[pietroalbini]

Note that with the implementation I have in mind adding more scopes should be trivial impl wise, so if anyone watching this issue has other needs let's discuss them!