global scoped installations or keys always scare me for this reason

i believe the answer here was to exchange the token for something scoped to the specific repo coderabbit is running in, but alas, that doesn't remove the "RCE" _on_ the repo

▲

tadfisher 6 days ago | parent [-]

They do that, this is how GH apps work. There is no reason to expose the app's private key in the environment for the code that actually runs on the PR.

▲

thewisenerd 6 days ago | parent [-]

even if they did not have the PEM file left in the environment, the token is still widely scoped and has the same scope as the PEM

what i'm clearly mis-remembering is being able to exchange the token for a smaller scope e.g., hey~ sign this jwt, with scopes=[org/repo1, org/repo2, permissions=write]

▲

deathanatos 6 days ago | parent [-]

> the token is still widely scoped and has the same scope as the PEM

What the person above you is trying to tell is you is that no, it doesn't.

The authentication flow is that the private key is used to sign an initial JWT; that gets you access to some GH API calls. From there you exchange that JWT for an access token with smaller scope, scoped only to the installation in question.

While the tool execution environment ought to have had none of the credentials, there is the possibility of only holding onto the installation access token.

	▲	thewisenerd 5 days ago \| parent [-]
		ah; understood. assuming PEM leakage aside the scope of the exchanged token is the scope of the installation (org / repo); thereby limiting exposure already to further reduce the scope of exposure, the jwt would've needed to be exchanged with the specific `repositories` (given most installations are org scoped) and `permissions` https://docs.github.com/en/apps/creating-github-apps/authent...