Repository navigation
gh secret set with body changes secret visibility #8110
Description
Activity
- addedgh-secretrelating to the gh secret commandrelating to the gh secret command
on Oct 3, 2023 @spinningarrow : thank you for opening up this issue and my apologies for the trouble caused! 🙇
Do you know that
gh secret sethas-v,--visibilityflag that defaults toprivatejust like the GitHub REST API for creating or updating org secrets?In your example command above, the
-v,--visibilityflag is not being specified, so the default value is being honored:-v, --visibility string Set visibility for an organization secret: {all|private|selected} (default "private")
The underlying "Create or update an organization secret" endpoint requires a visibility be provided when creating or updating an organization secret; the GitHub CLI has provided a security-minded default.
- addeddiscussFeature changes that require discussion primarily among the GitHub CLI teamFeature changes that require discussion primarily among the GitHub CLI teamand removedneeds-triageneeds to be reviewedneeds to be reviewed
on Oct 9, 2023 @andyfeller yes I saw that, but unless I'm missing something - that's quite hard to use in this scenario.
Ideally I'd want the visibility to be the same, without knowing what it is now. Especially in the case of multiple selected repos, when I update (rotate) the secret value, I don't want to change it's visibility at all, only the value.
Maybe there's a way to fetch the current visibility of the secret and then re-use that value?
Reacted by Andy Fellerthat's quite hard to use in this scenario.
I will admit it raises the question of why this endpoint was designed this way rather than allowing users to update aspects of a secret. As this I'm personally curious as to the reasoning, I want to see if I can get a good answer for the reasoning here.
Maybe there's a way to fetch the current visibility of the secret and then re-use that value?
Get an organization secret endpoint returns a URL string to List selected repositories for an organization secret for the specific organization secret that would need to be processed before calling Create or update an organization secret with an array of integers.
In order to add this support, the GitHub CLI would need to:
- Fetch all of this information about the secret
- Lookup IDs for each of the selected repositories
- Formulate a new API call to update the specific secret
In the mean time, there could have been changes made to the secret, which would be lost potentially. 🤔
@samcoe @williammartin : after talking with one of our beloved Actions hubbers, I don't think there are any security or product concerns if we wanted to add a flag that preserved this information when updating an org secret. that said, I'd appreciate any thoughts you'd like to add here.
Reacted by Sahil BajajI am not opposed, but I think it would be nice if this was directly supported by the API instead of us having the find each selected repository ourselves. Is there any indication that the API team is going to add in support for this? If we do move this direction we should also update
variable setto have the same functionality.Reacted by William MartinAgree with Sam, seems unfortunate there's no patch behaviour available.
I am not opposed, but I think it would be nice if this was directly supported by the API instead of us having the find each selected repository ourselves. Is there any indication that the API team is going to add in support for this? If we do move this direction we should also update
variable setto have the same functionality.I agree; I rather the API did this natively. My conversation left off on whether the other endpoints in use versus the methods available to see if it was doable. I will at least follow up internally to file a feature request to formally start the conversation.
a flag that preserved this information when updating an org secret
thanks for following up internally - this would be perfect!
Reacted by Andy Feller- addeddiscussFeature changes that require discussion primarily among the GitHub CLI teamFeature changes that require discussion primarily among the GitHub CLI teamand removeddiscussFeature changes that require discussion primarily among the GitHub CLI teamFeature changes that require discussion primarily among the GitHub CLI team
on Oct 31, 2023 This feels like it is the same issue as #6327, both have good context though so I think we can leave both open. Now at least they are linked from each other.
Reacted by Andy Feller and Shane McLaughlinHi, is there any update on this issue?
I am encountering the same problem described in #9383. I need to update the visibility of many organization secrets, and the current API limitations make this difficult to automate. Having support for updating the visibility without resubmitting the secret value would be very helpful.- addedpriority-2Affects more than a few users but doesn't prevent core functionsAffects more than a few users but doesn't prevent core functions
on Mar 9, 2026 Hi, is there any update on this issue?
Have followed up internally with our platform team on the internal issue created.
Describe the bug
I created some organization secrets using the GitHub web UI. For the secrets' visibility I chose "Selected repositories" and choose a few repositories.
I subsequently update the secrets' values using this command:
This changed the secrets' visibility settings from "Selected repositories" to "All private repositories". This is unexpected and bad for security since it elevates a secret's visibility.
Steps to reproduce the behavior
Expected vs actual behavior
Expected: Visibility remains the same i.e. selected repos
Actual: Visibility changes to private repos