I'm owner for my company of a few crates published on crates.io. However, relying on an individual in a company is kind of risky in the case of a compromised token for example (I might be on vacation or might even change company): I wouldn't be able to revoke the token fast enough or at all.
For most of the crates under my company's umbrella, we associated a Github team with them (the team appears as an additional owner of the crates). I'd thought I would be able to create tokens associated to the team so if I happen to not be available to revoke a token, any other member of the team would be able to do so. But I couldn't find how to create a token associated to the team (and not to a user). Did I miss something? Or am I looking for something that doesn't exist?
If a team name is given to --add , that team is invited as a “team” owner, with restricted right to the crate. While they have permission to publish or yank versions of the crate [...]
Since I believe I need a token to publish a crate, I'm assuming it should be possible to obtain a team's token. But I couldn't find how so here I am, trying to ask for help from the experts
You could just use the repository. There is nothing about cargo that is inherently tied to crates.io, that's just the default and official registry. If you're comfortable with the company's ownership of the repository, this should fit the bill. You can also use your own registry that mirrors crates.io and includes your packages. Most of these docs seem to be complete but the part about mirroring is still in progress.
Tokens are always personal, for an individual user. Teams only control which people can use their personal tokens on your team-owned crates.
Be careful that it's not possible to add or remove crate owners via team-owner, so a crates.io crate has to be directly owned by at least one user github account.
You may want to create a separate Github account that just handles publishing credentials, with the password for the user controlled by your team in whatever way you'd like.
Thank you. Would it make sense to make it explicit anywhere in the documentation (I'm willing to help if needed).
I have a problem to understand these 2 statements. If a team cannot add or remove crate owners, how can they control which people can use their personal tokens ?
Especially, I couldn't find a "Settings" page for teams in crates.io or anything similar, so I don't understand how to do anything with a team in crates.io.
In any case, I'm pinning your message as the solution since it does answer to my original question.
Thank you for your answer. However, it doesn't seem like a solution in my case since the crates are open-source, and I'd like them to be published on crates.io to increase their visibility. A private registry or using only Github repositories wouldn't achieve that goal.
On crates.io crates are owned by individual users who log in directly with their personal GitHub account.
On crates.io teams don't really own crates. "team owners" are just an authorization mechanism that allows other GitHub users (who are part of the GH team, but not necessarily crates.io crate owners) to publish new releases.
In all cases interaction with crates.io is done via personal GitHub accounts, not via team/org account.
Putting the git URL in a Cargo.toml would not preclude it from being on crates.io. The docs show rand as an example, which is the most-downloaded package on crates.io.
Misusing a user account by giving out the password to the whole company seems like a disaster waiting to happen. GitHub organizations exist for the exact purpose of managing access to repositories without having to contradict the purpose of security features like passwords, keys and 2FA.
For what it's worth, there's an RFC for "scoped tokens" on crates.io, and I've proposed using GitHub teams as the unit of scoping. There's some good discussion downthread from there about pros and cons, including what's mentioned here: crates can't be fully owned by a team on crates.io, they can just have team publish rights.
You might also be interested in these issues on crates.io, regarding ways to protect against / recover from compromise:
Another solution for your particular use case would be to make sure multiple other people at your company are owners on your crates. If your token is compromised, they can remove you as an owner, which will prevent your token from being used to publish. It's less convenient than managing everything through GitHub Teams, but it should get the job done.
