Misleading help message and undocumented GitHub token behavior

[yuto0214w]

TL;DR

• The behavior of cargo-binstall reading the result of gh auth token is not documented.
• The help message indicating cargo-binstall will try to extract GitHub token from file $HOME/.config/gh/hosts.yml, is incorrect from commit 8a08cdd onwards.
• At the same time, I feel like validity of GitHub token should be checked before used or at least, show some error if GitHub token was invalid.

Current help message of --no-discover-github-token:

cargo-binstall/crates/bin/src/args.rs

Lines 208 to 212 in 277269f

	/// If `--github-token` or environment variable `GITHUB_TOKEN`/`GH_TOKEN`
	/// is not specified, then cargo-binstall will try to extract github token from
	/// `$HOME/.git-credentials` or `$HOME/.config/gh/hosts.yml` by default.
	///
	/// This option can be used to disable that behavior.

Current help message of --github-token:

cargo-binstall/crates/bin/src/args.rs

Lines 364 to 372 in 277269f

	/// Provide the github token for accessing the restful API of api.github.com
	///
	/// Fallback to environment variable `GITHUB_TOKEN` if this option is not
	/// specified (which is also shown by clap's auto generated doc below), or
	/// try environment variable `GH_TOKEN`, which is also used by `gh` cli.
	///
	/// If none of them is present, then binstall will try to extract github
	/// token from `$HOME/.git-credentials` or `$HOME/.config/gh/hosts.yml`
	/// unless `--no-discover-github-token` is specified.

Details

When I try to install bat using cargo-binstall, the program fails to fetch repo information and fallback to compile.
My install log looks like this:

C:\Users\Admin>cargo binstall bat
 INFO resolve: Resolving package: 'bat'
 INFO get_repo_info{self=Data { name: "bat", version: "0.25.0", repo: Some("https://github.com/sharkdp/bat"), repo_info: OnceCell { value: None } }}:get_repo_info{repo=GhRepo { owner: "sharkdp", repo: "bat" }}:do_send_request{request=Request { method: POST, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.github.com")), port: None, path: "/graphql", query: None, fragment: None }, headers: {"accept": "application/vnd.github+json", "authorization": Sensitive} } url=https://api.github.com/graphql}: Received status code 401 Unauthorized, will wait for 120s and retry
 WARN resolve: Timeout reached while checking fetcher invalid url: deadline has elapsed
 WARN resolve: Timeout reached while checking fetcher invalid url: deadline has elapsed
 WARN resolve: Timeout reached while checking fetcher invalid url: deadline has elapsed
 WARN resolve: Timeout reached while checking fetcher QuickInstall: deadline has elapsed
 WARN The package bat v0.25.0 will be installed from source (with cargo)
Do you wish to continue? [yes]/no

After some investigations, I found that

• cargo-binstall had used the gh-token crate when the help message was written (commit 44ac63c)
• After that, gh-token crate has removed, and rewritten to use the result of gh auth token (commit 8a08cdd)
  • (At the same time, the behavior of reading the file $HOME/.config/gh/hosts.yml was not inherited from the crate, but corresponding help messages were not updated)
• This would cause the issue because cargo-binstall references GitHub token from the result without checking its validity, so requests from this program may fail with 401.
  • For example, if GitHub CLI hasn't been used by the user for a long period of time, the user may experience this issue as the token is not automatically refreshed by GitHub CLI (which was my case.)

I've resolved the issue by applying --no-discover-github-token to the argument, but I feel like this behavior should be an error rather than falling back to compile.

[NobodyXu]

Thanks for reporting!

For the documentation issue, I'd accept pull requests fixing them.

For 401 when invalid token is used, I think we have code handling that, by falling back to not using the github token if that happens.