You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
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:
I imagine the current documentation updated to something like:
https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner
Is this a change with broad appeal?
The text was updated successfully, but these errors were encountered: