> You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token

This is a failure of the GH CLI, IMO. If you log into the GH CLI, it gets access to upload repositories, and doesn’t require frequent re-auth. Unlike AWS CLI, which expires every 18hr or something like that depending on the policy. But in either case (including with AWS CLI), it’s simply too easy to end up with tokens in plaintext in your local env. In fact, it’s practically the default.

▲

madeofpalk 5 days ago | parent [-]

gh cli is such a ticking time bomb. Anything can just run `gh auth token` and get a token that probably can read + write to all your work code.

▲

awirth 5 days ago | parent [-]

These tokens never expire, and there is no way for organization administrators to get them to expire (or revoke them, only the user can do that), and they are also excluded from some audit logs. This applies not just to gh cli, but also several other first party apps.

See this page for more details: https://docs.github.com/en/apps/using-github-apps/privileged...

After discussing our concerns about these tokens with our account team, we concluded the only reasonable way to enforce session lengths we're comfortable with on GitHub cloud is to require an IP allowlist with access through a VPN we control that requires SSO.

https://github.com/cli/cli/issues/5924 is a related open feature request

	▲	0xbadcafebee 5 days ago \| parent [-]
		That is crazy. See, this is what I'm talking about. It shouldn't even be possible to have services that sensitive with auth tokens that can't expire.