Replies: 1 comment
-
Hi @panva! We appreciate your feedback and your valuable input. We want to be transparent about our current priorities. You can gain insights into the projects we’re currently focusing on for the upcoming year by checking our public roadmap. While smaller fixes may not always be explicitly listed, they often get addressed when related work is in progress. Regarding your specific request, it’s important to note that it’s not actively being worked on at the moment. However, this doesn’t mean we won’t consider it in the future; it’s simply not on our development roadmap right now. We’d like to emphasize that as a valued GitHub user, your feedback in this Discussion space, along with appropriate tags and examples, plays a crucial role in shaping the development of GitHub. While we can’t guarantee immediate action on every piece of feedback, please rest assured that we are attentive to your suggestions and continuously strive to enhance the GitHub experience. While we do review all incoming feedback unfortunately due to the volume of feedback, we may not be able to respond to each one individually at this time. However, we strongly encourage you to continue providing your valuable input as it greatly helps us prioritize and improve GitHub. Your contributions are instrumental in making GitHub better for all users. Thank you for taking the time to share your thoughts with us, even if the particular request is not currently in active development. Your input is truly valuable and contributes to the continuous improvement of GitHub. |
Beta Was this translation helpful? Give feedback.
-
Having a number of packages for which I wish to have expiring granular access tokens I find myself struggling to be able to go through a rotation quickly and efficiently in such a way that I am not discouraged from just setting the expiration to years, leading to bad secret practices.
My goal is to have 1 granular access token per package which expires in <as short as I'm willing to repeat the rotation process> and has the github actions CIDR addresses (from which I publish using provenance).
This is currently absolutely impossible to setup for even a single package because of how clunky the IP ranges UI is.
Here are my suggestions to make the UI and UX better.
Have a refresh action button in the UI
this button takes all attributes of the existing token and pre-sets them in the create view
put two more date ranges in the UI - 6 months and 1 year, given how unfriendly the process is I'm unwilling to repeat this process any more frequent than 1 year.
Improve the IP ranges UI - make it a textarea element where each line is an additional range
better IP ranges integration with known CI services - allow me to select a CI product to tie the range to, it shouldn't be impossible for npm to sync the ranges with e.g. github's ranges from the API github provides so that I can just select github actions and know the token's only usable from there for the token's duration.
originally posted in npm/feedback#1107
Beta Was this translation helpful? Give feedback.
All reactions