Custom permissions is a cosmetic change

[t3mi]

Is that correct? I'm asking because it's not clear from the docs whether the scopes of the access token would be enforced to contain only specified custom permissions if such were defined or these permissions-* inputs should be used purely as documentation source and access token would still contain all the permissions defined for the app install.

[gr2m]

No, it's not a cosmetic change. If you defined a set of permissions using the inputs, the resulting installation access token will only have these permissions. You can see the code where the token is created in these two places

1. create-github-app-token/lib/main.js

   Lines 142 to 146 in c3c17c7

   	const authentication = await auth({
   	type: "installation",
   	installationId: response.data.id,
   	permissions,
   	});

2. create-github-app-token/lib/main.js

   Lines 171 to 176 in c3c17c7

   	const authentication = await auth({
   	type: "installation",
   	installationId: response.data.id,
   	repositoryNames: parsedRepositoryNames,
   	permissions,
   	});

This is the REST API endpoint we use, you can read in the docs about the permissions argument that we pass to it, if permissions are set using the input:
https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app

[t3mi]

Thanks for the prompt response! I saw a PR but had a hard time understanding how that's working. I wasn't able to find a GitHub endpoint which could show the scopes token was issued for so I configured a test repo with a simple workflow which gets token using GitHub app with custom permissions defined and use that token subsequently in the GitHub script action to probe various endpoints using GET (the script was generated using AI so you can disregard few non-existent functions)).

Application is having permissions configured like so

checks: read
contents: read
issues: read
metadata: read
pull-requests: read
statuses: read

Action should generate a token only with metadata and issues .
But the run shows that permissions were not restricted and all granted permissions by the app are active for the token. Also, you could see that, for example, web hook endpoint is throwing the lack of permission.
Once I updated the application to include read permission for the web hook with subsequent confirmation on the app install (without updating the workflow itself), next run shows that web hook endpoint started answering. Per my understanding, custom permissions aren't working correctly in this case or Im missing something?

[gr2m]

thanks for the through digging into this and for sharing your findings. I'll try to reproduce it on my end and see what I can find out, but can't promise on when I'll be able to do that.

[parkerbxyz]

Thanks again for your efforts here, @t3mi! We found and fixed the bug causing this problem. The fix is in v2.0.4.