-
-
Notifications
You must be signed in to change notification settings - Fork 121
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
Authorization tokens are easy to lose track of #364
Comments
I see #165, for example, but it didn't appear to ever get any traction and appears dead at this point. |
Yeah, some sort of name or label sounds great! Thanks for offering. |
Thanks for the feedback, @indirect! I realize I missed something above: a way to list the current authorizations, with their names and capabilities, to make sure you're revoking the right thing. Is that also something you'd support? |
Yeah, absolutely. |
Alright, keep an eye out for a PR then. Thanks for the quick responses! |
Over time, gemstash authorizations turn into a pile of opaque tokens and associated permissions. Keeping track of which token belongs to which developer or automated system is required to enabled proper revocation or rotation. Today, that requires the use of an external system, which has the added problem of duplicating the key itself. Support keeping this association within Gemstash itself by allowing for authorizations to be named. Also support listing authorizations, so it's easy to determine which key needs to be revoked, rotated, or otherwise updated. See the manpage updates for details on use. Resolve rubygems#364 Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
Over time, gemstash authorizations turn into a pile of opaque tokens and associated permissions. Keeping track of which token belongs to which developer or automated system is required to enabled proper revocation or rotation. Today, that requires the use of an external system, which has the added problem of duplicating the key itself. Support keeping this association within Gemstash itself by allowing for authorizations to be named. Also support listing authorizations, so it's easy to determine which key needs to be revoked, rotated, or otherwise updated. See the manpage updates for details on use. Resolve rubygems#364 Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
Over time, gemstash authorizations turn into a pile of opaque tokens and associated permissions. Keeping track of which token belongs to which developer or automated system is required to enabled proper revocation or rotation. Today, that requires the use of an external system, which has the added problem of duplicating the key itself. Support keeping this association within Gemstash itself by allowing for authorizations to be named. Also support listing authorizations, so it's easy to determine which key needs to be revoked, rotated, or otherwise updated. See the manpage updates for details on use. Resolve #364 Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
We've been using the private gem functionality of gemstash for a number of years now, with great success. However, as both our team and our CI systems have changed a little over time, we're hitting a pain point: we need to keep careful notes of which token belongs to each developer or system, so we can revoke tokens when they're no longer used. This feels like a feature that could be easily added to gemstash, and if we agree on a design I'd be happy to add it. I'm thinking something really simple:
Thoughts?
The text was updated successfully, but these errors were encountered: