Token storage change in latest release of gh

This is a message from the GitHub CLI team, maintainers of gh, writing to inform you that the most recent release of gh contains changes which may affect your extension. The latest release introduces the feature of storing authentication tokens in the system keyring (encrypted storage) instead of in a plain text file.
The keyrings that are supported are:

• Keychain on macOS

• GNOME Keyring on Linux (Secret Service dbus interface)

• Wincred on Windows

This has huge security benefits for the users of our tool and was one of our oldest outstanding issues. Unfortunately this change has the potential to break extensions that rely on utilizing the users authentication token to work.

In order to have continued compatibility with gh there are some actions you, as an extension author, need to take. These actions will depend on the implementation of your extension.

Extensions built in Go using go-gh:

1. Upgrade your go-gh version to v1.2.1, the latest version.

   • This can be done using go get github.com/cli/[email protected]

2. Verify that in your extension retrieval of the user authentication token is done using the auth.TokenForHost function.

   • If you were previously accessing the authentication token using any other method it will no longer work.
   • Automatic resolution of the authentication token when using the API clients will continue to work without changes.

All other extensions:

1. Verify that in your extension retrieval of the user authentication token is done by shelling out to the gh auth token command.

   • If you were previously accessing the authentication token using the gh config get command, reading the configuration file directly, or any other methods it will no longer work.

As of right now storing the authentication token in the system keyring is an opt-in feature, but in the near future it will be required and at that point if the changes above are not made then your extension will be broken for all users. If you have any questions/concerns about this change please feel free to open a discussion in the gh repo.

Thanks,
The GitHub CLI Team

Thanks for this extension! I've already found it very useful.

I'm curious: would it be possible to modify this to also include remote branches? I would be more than happy to work on adding that, but I'm honestly not entirely sure where to start.

ctrl+d is often used in REPLs (e.g. node, deno, irb) as an exit command. Looks like this extension has ctrl+d bound to silently force(!!!) delete branches. I deleted two branches before I realized what was happening. Seems like it would be better to choose a different shortcut for deleting branches or at least add some confirmation before doing so.

Congrats on being featured in the GitHub CLI 2.0 release blog :)

I'm seeing some unexpected results when I run the extension:

I have two other local feature branches (one whose PR is merged, one whose PR is not) that are not showing up.

Not sure if this is relevant or not, but this repo's origin remote is on a GitHub Enterprise Server instance, but the GitHub CLI is authenticated to it.

Thanks in advance for any help you can offer!

https://hacktoberfest.digitalocean.com/faq

You can politely request the maintainer of the project you contributed to, to tag your contribution with the label hacktoberfest-accepted . Or, add the 'hacktoberfest' topic to the repository to opt the project into Hacktoberfest.

Any pull request with the hacktoberfest-accepted label, submitted to any public GitHub/GitLab repository, with or without the hacktoberfest topic, will be considered valid for Hacktoberfest.

Any way we can add the topic?

A small but nice feature would be to have the script not open an empty window when calling it from outside a repo.

First of all, THANKS for your extension!

I've installed it today and some branches didn't appear and I think that it's because of the branch_info method

branch_info() {
  git for-each-ref 'refs/heads/*' --format='%(refname:short)%09%(committerdate:unix)%09%(committerdate:relative)%09%(HEAD)'
}'

The problem seems to be the refs/heads/*' instead of refs/heads/**.

I'll show some examples:

Thanks in advanced and if you need anything just tell me!

PD: If you think that what I'm telling you is correct I will have not problem in open a PR!