Skip to content

gh secret set with body changes secret visibility #8110

Description

@spinningarrow

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:

      gh secret set $SECRET_NAME -b "$SECRET_VALUE" -o $ORG_NAME -a actions

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

  1. Go to a github org
  2. Create a secret
  3. Change it's visibility to 'selected repos' and choose some repos
  4. Update the secret value using the CLI
  5. Check the updated secret's visibility

Expected vs actual behavior

Expected: Visibility remains the same i.e. selected repos
Actual: Visibility changes to private repos

Activity

  1. andyfeller commented on Oct 9, 2023

    @andyfeller
    Contributor

    @spinningarrow : thank you for opening up this issue and my apologies for the trouble caused! 🙇

    Do you know that gh secret set has -v,--visibility flag that defaults to private just like the GitHub REST API for creating or updating org secrets?

    In your example command above, the -v,--visibility flag 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.

  2. added
    discussFeature changes that require discussion primarily among the GitHub CLI team
    and removed on Oct 9, 2023
  3. spinningarrow commented on Oct 9, 2023

    @spinningarrow
    Author

    @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?

  4. andyfeller commented on Oct 18, 2023

    @andyfeller
    Contributor

    that'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:

    1. Fetch all of this information about the secret
    2. Lookup IDs for each of the selected repositories
    3. 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. 🤔

  5. andyfeller commented on Oct 18, 2023

    @andyfeller
    Contributor

    @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.

  6. samcoe commented on Oct 19, 2023

    @samcoe
    Contributor

    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 set to have the same functionality.

  7. williammartin commented on Oct 19, 2023

    @williammartin
    Member

    Agree with Sam, seems unfortunate there's no patch behaviour available.

  8. andyfeller commented on Oct 20, 2023

    @andyfeller
    Contributor

    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 set to 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.

  9. spinningarrow commented on Oct 23, 2023

    @spinningarrow
    Author

    a flag that preserved this information when updating an org secret

    thanks for following up internally - this would be perfect!

  10. added
    discussFeature changes that require discussion primarily among the GitHub CLI team
    and removed
    discussFeature changes that require discussion primarily among the GitHub CLI team
    on Oct 31, 2023
  11. samcoe commented on Nov 7, 2023

    @samcoe
    Contributor

    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.

  12. andyfeller commented on Jul 29, 2024

    @andyfeller
    Contributor

    With @yvele touching on this in #9383, I'm going to re-engage internally to see what might be done at the API layer to provide relief for this issue as doing it client side isn't ideal.

  13. clmssz commented on Mar 9, 2026

    @clmssz

    Hi, 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.

  14. added
    priority-2Affects more than a few users but doesn't prevent core functions
    on Mar 9, 2026
  15. williammartin commented on Mar 11, 2026

    @williammartin
    Member

    Hi, is there any update on this issue?

    Have followed up internally with our platform team on the internal issue created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdiscussFeature changes that require discussion primarily among the GitHub CLI teamgh-secretrelating to the gh secret commandpriority-2Affects more than a few users but doesn't prevent core functions

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions