Something that's come up as part of the prefix / namespace reservation changes is that while it's possible for us to figure out existing gems ownerships (regarding organizations) it's hard to identify new gem pushes as owned by an organization. There's some proposed changes here #6762 to use the gemspecs metadata to include the organization's handle. This would be an accompanying change which would give a more robust set of api keys management for admins within an organization to create / manage api keys with access to the gems owned by the org.
The intent here is to provide a way for the organization to revoke the permissions should a member have their account/ keys compromised.
As a user we want to use a similar form to the users one to create / manage the keys only for the organizations gems.
TO BE ANSWERED
- Should these be used alongside the personal keys of users? As in a user is able to push personal gems AND org gems?
- Should these be not scoped to a individual user account at all?
- How would this affect trusted publishing?
Something that's come up as part of the prefix / namespace reservation changes is that while it's possible for us to figure out existing gems ownerships (regarding organizations) it's hard to identify new gem pushes as owned by an organization. There's some proposed changes here #6762 to use the gemspecs metadata to include the organization's handle. This would be an accompanying change which would give a more robust set of api keys management for admins within an organization to create / manage api keys with access to the gems owned by the org.
The intent here is to provide a way for the organization to revoke the permissions should a member have their account/ keys compromised.
As a user we want to use a similar form to the users one to create / manage the keys only for the organizations gems.
TO BE ANSWERED