[captn3m0]

https://docs.github.com/en/actions/how-tos/deploy/configure-... is the feature they use.

> We impose tag protection rules that prevent release tags from being created until a release deployment succeeds, with the release deployment itself being gated on a manual approval by at least one other team member. We also prevent the updating or deletion of tags, making them effectively immutable once created. On top of that we layer a branch restriction: release deployments may only be created against main, preventing an attacker from using an unrelated first-party branch to attempt to bypass our controls.

> https://astral.sh/blog/open-source-security-at-astral

From what I understand, you need a website login, and not a stolen API token to approve a deployment.

But I agree in principle - The registry should be able to enforce web-2fa. But the defaults can be safer as well.

[jonchurch_]

I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo)

Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this on, and it was an approval gated GHA job that I had claude approve using my GH cli token

I also had claude use the same token to first reconfigure the enviornment to enable self-approves (I had configured it off manually before testing). It also put it back to self approve disabled when it was done hehe

[1] https://github.com/jonchurch/deploy-env-test/actions/runs/25...

[captn3m0]

You're right. Found the relevant docs+API calls:

https://docs.github.com/en/rest/actions/workflow-runs?apiVer...

Also for a Pending Deployment: https://docs.github.com/en/rest/actions/workflow-runs#review...

Both of these need `repo` scope, which you can avoid giving on org-level repos. For fine-grained tokens: "Deployments" repository permissions (write) is needed, which I wouldn't usually give to a token.

[deathanatos]

sigh Github's idiotic fractal of authentication types.

What upthread is talking about is the Github CLI app, `gh`; it doesn't use a fine-grained tokens, it uses OAuth app tokens. I.e., if you look at fine grain tokens (Setting → Developer settings → Personal access tokens → Fine-grained token), you will not see anything corresponding to `gh` there, as it does not use that form of authentication. It is under Settings → Applications → Authorized OAuth Apps as "Github CLI".

I just ran through the login sequence to double-check, but the permissions you grant it are not configurable during the login sequence, and it requests an all-encompassing token, as the upthread suggests.

Another way to come at this is to look at the token itself: gh's token is prefixed with `gho_` (the prefix for such OAuth apps), and fine-grained tokens are prefixed with `github_pat_` (sic)¹

¹(PATs are prefixed with `ghp_`, though I guess fine-grained tokens are also sometimes called fine-grain PATs… so, maybe the prefix is sensible.)

[captn3m0]

I’m paranoid but I never authenticate the GitHub CLI - there should be no tokens lying around on my system. If needed, I have some scoped PATs in pass, which I can source as env variables. Git Pushes happen over SSH with Yubikey.