link- / gh-token Goto Github PK

looks like this is affected by cli/cli#8475 as well or am i missing something?

Provided --revoke and an -t | --token <token> the latter will be revoked.

revoke  Revokes supplied installation access token
    -t | --token  Access token to revoke

Currently only the server to server token creation flow has been implemented.

Another very useful token would be the OAuth access token more specifically the Device flow.

This issue is to implement the device flow.

cc: @jonico

If the app is installed on multiple organisations only the latest installation id will be retrieved and used. This will prevent the end user from specifying which organisation they are targeting with their requests.

This feature is to implement a new parameter that allows the user to specify which installation-id they'd like to use for authorisation.

-l | --installation-id <id>  GitHub app's installation id (Default: latest)

Develop a PoC to integrate this tool with AWS KMS and Azure Key Vault respectively.

Hi and thanks for this great script!
I have been playing around with it during last days and it has worked mostly fine and usually the errors are something that I did :D

I reinstalled my WSL-machine and something changed, because I started getting an error constantly saying:
"! failed to fetch installation id"

After debugging I got these errors from the installation ID fetch logic:
"message": "'Expiration time' claim ('exp') is too far in the future"

I knew that GitHub maximum for token expiration was 10mins and somehow my systems time was off synch half a second or something :) I tried to fix it with NTP etc, but nothing worked.I found some communication from different forums that when the endpoint (GitHub) is really strict about this, you should basically not call the maximum expiration time never. Usually the workaround was to decrease the expiration payload by one second so minor off-synch was allowed.

So all it took was to change the JWT-token generation line to:
-e $(( $(date +%s) + $(( _duration * 60 -1 )) )) \

https://github.community/t/expiration-time-claim-exp-is-too-far-in-the-future-when-creating-an-access-token/13830/2#M1127

Don't know if this is something that should be in the code, but atleast it's documented here if someone else gets this problem!

jwt-cli 5.0.0 has been released with a breaking change. Update the script to support the latest version.

https://github.com/mike-engel/jwt-cli/releases/tag/5.0.0

gh token generate --app-id XXXXX --base64_key ABDC

returns

Error: either --key or --key-base64 must be specified

when using --key-base64

gh token generate --app-id XXXXX --key-base64 ABDC

returns

Error: flag provided but not defined: -key-base64

The CLI helps options doesn't show the existence of the --key-base64 parameter

   --app-id value, -i value, --app_id value                    GitHub App ID
   --installation-id value, -l value, --installation_id value  GitHub App installation ID. Defaults to the first installation returned by the GitHub API if not specified
   --key value, -k value                                       Path to private key
   --base64-key value, -b value, --base64_key value            A base64 encoded private key
   --hostname value, -o value                                  GitHub Enterprise Server API endpoint, example: github.example.com (default: "api.github.com")
   --token-only, -t                                            Only print the token to stdout, not the full JSON response, useful for piping to other commands (default: false)
   --jwt, -j                                                   Return the JWT instead of generating an installation token, useful for calling API's requiring a JWT (default: false)
   --duration value, -d value                                  The expiry time of the JWT in minutes up to a maximum value of 10, useful when using the --jwt flag (default: 1)
   --silent, -s                                                Do not print token to stdout (default: false)
   --help, -h                                                  show help```

I followed the installation instructions, but got an error:

►  gh extensions install Link-/gh-token
...
✓ Installed extension Link-/gh-token
►  gh token
/Users/laughedelic/.local/share/gh/extensions/gh-token/gh-token: line 858: syntax error in conditional expression: unexpected token `('

I tried installing it via curl and got the same error. My guess was that

is a "new" Bash feature, and the Bash preinstalled on macOS is old:

►  /usr/bin/env bash --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin21)
Copyright (C) 2007 Free Software Foundation, Inc.

►  brew info bash
bash: stable 5.1.16 (bottled), HEAD

So I installed Bash from Homebrew, and it fixed the problem.

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

When an installation access token expires, the APIs return a refresh token that can be used to create another installation access token.

-r | --refresh <expired token>  Uses an expired token to request a new access token.

I installed gh and ghtoken on Ubuntu. Getting following error while generating the token:

Error

ghtoken generate --key /opt/key --app_id 154278 --install_jwt_cli shasum: jwt-linux.tar.gz: No such file or directory ! /usr/local/bin/ghtoken: line 112: Could not verify validity of the downloaded package.: command not found Aborting due to errexit on line 112. Exit code: 127

Versions

OS: Ubuntu:22.04 gh: 2.2.0 ghtoken: 0.2.0-alpha

Obviously bash is a headache and not cross-platform. It's important to make this helper tool available on as many platforms as possible and with go that's feasible.

This is related to #3.

Sometimes the user doesn't know the installation id to use so the interactive mode will list the available ids for them to pick one.

-n | --interactive-mode  Enabled interactive mode to select installation id (Default= false)