Reconfigure credentials when persist-credentials: false is set

[tobigumo]

actions/checkout persists Git credentials by default, making them available to subsequent jobs. However, from a security perspective, it's preferable to set persist-credentials: false so that credentials are removed during cleanup.
actions/checkout#485

Meanwhile, stefanzweifel/git-auto-commit-action assumes the credentials remain from the initial checkout. If persist-credentials: false is specified, an error occurs due to missing credentials.
Currently, you can avoid this error by manually resetting the credentials with git remote set-url before stefanzweifel/git-auto-commit-action runs.

- run: |
    git remote set-url origin https://$GITHUB_ACTOR:${{ secrets.GITHUB_TOKEN }}@github.com/$GITHUB_REPOSITORY

I would like to request a new feature in stefanzweifel/git-auto-commit-action to reconfigure credentials automatically. Specifically, even when persist-credentials: false is used, the action itself would run git remote set-url or a similar command before execution to prevent errors.

Thank you for considering this feature request.

[tobigumo]

I came across a discussion #272 with the similar error, but in my case, it doesn't seem to be caused by the ref settings.
To be sure, I confirmed that I'm not in a detached HEAD state; I'm indeed on the correct branch:

Run git branch --contains
  git branch --contains
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
* test-branch

Below is the error I'm encountering:

Run stefanzweifel/git-auto-commit-action@e348103e9026cc0eee72ae06630dbe30c8bf7a79
  with:
    commit_message: infra: update snapshot
    file_pattern: .
    repository: .
    commit_user_name: github-actions[bot]
    commit_user_email: 41898282+github-actions[bot]@users.noreply.github.com
    commit_author: tobigumo <[email protected]>
    skip_dirty_check: false
    skip_fetch: false
    skip_checkout: false
    disable_globbing: false
    create_branch: false
    internal_git_binary: git
Started: bash /home/runner/work/_actions/stefanzweifel/git-auto-commit-action/e348103e9026cc0eee72ae06630dbe30c8bf7a79/entrypoint.sh
INPUT_REPOSITORY value: .
INPUT_STATUS_OPTIONS: 
INPUT_FILE_PATTERN: .
INPUT_BRANCH value: 
fatal: could not read Username for 'https://github.com': No such device or address
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/e348103e9026cc0eee72ae06630dbe30c8bf7a79/index.js:17:19)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
  code: 128
}
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/e348103e9026cc0eee72ae06630dbe30c8bf7a79/index.js:17:19)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5)

I have also confirmed that the error does not occur if I remove the persist-credentials: false entry.

[stefanzweifel]

Thanks for raising this issue and starting a discussion.

I wasn't aware that the persist-credentials-options exists in actions/checkout. And I can understand why the current behaviour of actions/checkout can be seen as a security issue.

However, wouldn't we replicate the exact same issue when we would add your workaround into the action itself?

- run: |
    git remote set-url origin https://$GITHUB_ACTOR:${{ secrets.GITHUB_TOKEN }}@github.com/$GITHUB_REPOSITORY

If we call git remote set-url, isn't the value then stored in the .git-directory and could be abused? Or would you also propose we add a "cleanup" function, that clears the token, once git-auto-commit has done its job?

---

Relying on actions/checkout has been a cheap escape hatch for me, as I then didn't have to care (or give tech support) on how users clone their repository. I could always easily say "please use actions/checkout or report an issue in their repo".

Besides, I currently don't see an obvious attack vector. Yes of course a workflow run gets a GITHUB_TOKEN with write permission, but you would still have to write your workflow in a specific way to create an issue.

I don't want to downplay the risk of relying on actions/checkout and their persistence of the credentials on disk. I'm more than happy to merge a PR that improves git-auto-commit in this regard or think about a path on how we could get there.