Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally grant teams the permission to modify owners #2906

Closed
michaelkirk opened this issue Oct 12, 2020 · 0 comments
Closed

Optionally grant teams the permission to modify owners #2906

michaelkirk opened this issue Oct 12, 2020 · 0 comments

Comments

@michaelkirk
Copy link

michaelkirk commented Oct 12, 2020

Currently you can add a GH team as an "owner". Members of that GH team can then publish the crate.

However, if someone from the team tries to edit the owners they get the message:

team members don't have permission to modify owners

I assume this is by design, as a way to help prevent someone getting their project hijacked or whatever.

However, I'm considering a use case where a small group of organization admins would be able to update the owners of any crates within the org. This is explicitly for the case when the original owner has abandoned their crate or become unresponsive. Having team ownership as it currently exists allows for us to continue publishing new versions indefinitely, but we would be hamstrung from ever fully owning the crate long term.

I can imagine this would also be useful in a corporate environment where, in general, assets are owned by roles, not users.

I can also imagine the inverse - you might like to give an individual user permission to publish your crate without conferring them the ability to hijack your crate long term. I don't personally have this particular use case, but I thought it might be good for symmetry.

If we did proceed with this, since things have worked in their current state for a while, it seems we'd want to keep all the default behavior as it is, and allow different behavior via some new flag. Maybe something like:

cargo owner --add github:some_org/some_team --allow-manage-owners
cargo owner --add some_user  --deny-manage-owners

I imagine the current documentation updated to something like:

https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner

To publish or yank versions of a crate, a user must have ownership of the crate. Ownership can be granted to individual users or to teams.

All owners may publish and yank versions of the crate. Additionally, some owners have the ability to add or remove owners, including the owner who made them an owner. Needless to say, only those you fully trust should have the ability to manage the crate's owners. Keep in mind that teams can be edited - so even team members added after the fact will have these abilities.

User's are granted permission to manage owners by default, but it can be disabled with --deny-manage-owners.

$ cargo owner --add some_user  --deny-manage-owners

Team's do not have permission to manage owners by default, and it must be enabled with --allow-manage-owners

$ cargo owner --add github:rust-lang:owners --allow-manage-owners

Is this a change with broad appeal?

@rust-lang rust-lang locked and limited conversation to collaborators Dec 23, 2021
@Turbo87 Turbo87 converted this issue into discussion #4349 Dec 23, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant