These labels are only used on PRs, so I'm pretty sure the issues: write can be removed. In addition, I think we might not even need the pull-requests: write since AFAICT we are not writing anything.
I don't have enough energy today to also dig into this to make sure that the permissions are not needed, so feel free to merge this as is and we can open a separate issue to investigate and possibly remove these.

Yep, we can check with this separately. This PR isn't adding any extra permissions here.

There's a git fetch in the next step. Wouldn't that still need the credentials in order to work?

I don't think it needs to be an authenticated git fetch?

It ran okay here: https://github.com/python/cpython/actions/runs/12225521755/job/34099604804

Yep, persist-credentials is only needed for git ops that need authentication. In the context of public repos and their workflows, in practice that means only ops that mutate the repo, rather than pulling from it 🙂

That makes sense, but if this is the case, does it also mean that as long as we are just reading from public repos, there are no credentials used so there's nothing to share with the other jobs?

IOW, persist-credentials: true would only be a concern when a token is used, either for mutating operations (e.g. pushes) or for accessing private repos, and in this case there's actually no security risk, right?

(It might still be better to explicitly add persist-credentials: false regardless though -- e.g. in case someone adds a token later.)

That makes sense, but if this is the case, does it also mean that as long as we are just reading from public repos, there are no credentials used so there's nothing to share with the other jobs?

Nope, unfortunately the default means that a credential is persisted, even though it isn't necessary. So persist-credentials: false actually does something usefully by explicitly removing the credential.

Thanks for your reply! I'm still not sure I understand if there is an actual issue with reading (i.e. with no writing/mutating operations) public repos though. I tried digging a bit deeper to understand and this is what I found.

The actions/checkout README says that it accepts both a token and an ssh-key (which we are not using):

# Personal access token (PAT) used to fetch the repository. The PAT is configured
# with the local git config, which enables your scripts to run authenticated git
# commands. The post-job step removes the PAT.
#
# We recommend using a service account with the least permissions necessary. Also
# when generating a new PAT, select the least scopes necessary.
#
# [Learn more about creating and using encrypted secrets](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)
#
# Default: ${{ github.token }}
token: ''

# SSH key used to fetch the repository. The SSH key is configured with the local
# git config, which enables your scripts to run authenticated git commands. The
# post-job step removes the SSH key.
#
# We recommend using a service account with the least permissions necessary.
#
# [Learn more about creating and using encrypted secrets](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)
ssh-key: ''

The comment for persist-credentials says:

# Whether to configure the token or SSH key with the local git config
# Default: true
persist-credentials: ''

So my understanding is that if I explicitly set a token/key with token: '...' or ssh-key: '...' and use persist-credentials: true (either explicitly or implicitly since it's the default), the token/key will be "persisted in the local git config" (which I assume is .git/config, i.e. it will be written on a file). This will expose the token/key to the other jobs -- which is a security risk.

If I don't explicitly specify any token/key (i.e. what we are doing in our workflows), actions/checkout will set github.token as default token and persist that. Since github.token is already available to all jobs, the fact that it is persisted shouldn't be an issue -- unless having its value written on a file poses a new threat that I'm not aware of.

Nope, unfortunately the default means that a credential is persisted, even though it isn't necessary.

If no credentials are passed explicitly by using token/ssh-key (which are not needed while reading public repos, like in our workflows) and assuming persist-credentials: true, either:

• there is no security issue (unless either a token or ssh-key are explicitly set);
• persisting github.token is still a security issue (maybe because it's written on a file?); ¹
• there's some other credential that I'm missing that causes a security issue;

No problem! Thanks for your detailed response as well.

Since github.token is already available to all jobs, the fact that it is persisted shouldn't be an issue -- unless having its value written on a file poses a new threat that I'm not aware of.

Yep: the risk with this is that it's easy to inadvertently upload/log/otherwise persist that local filesystem credential. This can't happen with the in-memory token (i.e. github.token) in the ordinary case.

For example, until recently, this would cause a token disclosure via a public artifact:

uses: actions/checkout

# other steps

uses: actions/upload-artifact
with:
  path: . # uploads the entire repo, including the persisted token

This post has some interesting/elucidative examples of that: https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/

1. if this is a problem, maybe setting token: '' explicitly will prevent the github.token to be used (and persisted) at all (depending on how the action is implemented) ↩

Yeah, I believe this will result in an empty string being saved on the filesystem for the token. I'm not 100% sure but I think this will cause GitHub API errors in some cases.

(I think persist-credentials: false is the intended way to disable github.token.)

This post has some interesting/elucidative examples of that: https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/

Thanks for sharing, this is really interesting!

Now that I have all the pieces of the puzzle it finally makes sense:

• GitHub automatically creates a github.token
• If no token: ... is specified in actions/checkout, then github.token is used
• If persist-credentials is true (the default), either the github.token or the specified token will be written in .git/config
• If the file containing the token becomes publicly accessible (e.g. uploaded via actions/upload-artifact) an attacker could access it and use it
• persist-credentials: false avoids writing the tokens on files and prevents token leaks

There are a few more caveats here and there, but this is already more than enough to justify the use of persist-credentials: false.

No problem! Your summary is great and matches my understanding perfectly 🙂