Clear CI token in git credential managers

Guillaume Chauvelrequested to merge
gitlab-community/gitlab-org/gitlab-runner:gchauvel/fix-credential-manager into main

What does this MR do?

This MR adds git credential reject calls at the end of get_sources and at the start of cleanup to clear the CI token from any user credential helper that may have stored it during the job. The erase is best-effort: if it fails, the job still succeeds and the rest of the cleanup still runs.

Only the username=gitlab-ci-token entry is removed for the matching host. Personal credentials stored under a different username are left untouched. The reject only affects credential helpers reachable from git's config chain at the moment the cleanup runs.

Why was this MR needed?

I sometimes run a gitlab-runner shell executor on my personal computer. When FF_GIT_URLS_WITHOUT_TOKENS is false, the gitlab-ci-token credentials get pushed to credential helpers, and then, after a build, when I fetch my own repos, the first fetch always fails because git tries to use the gitlab-ci-token credentials.

There are 3 approaches to prevent CI_JOB_TOKEN from leaking into credential helpers: prevent it from happening in the first place (1), clean up after the build (2), or shadow system and global configs (3).

  1. Reset the credential helper at the local (repo) level: this is what happens when FF_GIT_URLS_WITHOUT_TOKENS is true. The job overrides credential.helper in the local git config, so git never reads from (or writes to) the user's system credential managers during the job. This was also the approach first tried in !6599 (closed).
  2. Clear the CI token from the credential helpers after the get_sources phase and during cleanup: the approach taken in this MR. Git's credential chain works normally during the job, so a configured credential helper will store CI_JOB_TOKEN. We explicitly git credential reject the gitlab-ci-token username. Only the username=gitlab-ci-token entry is removed, so any personal credential stored under a different username is left untouched.
  3. Set GIT_CONFIG_NOSYSTEM to 1 and GIT_CONFIG_GLOBAL to point to .gitlab-runner.ext.conf (additional effect of !6665 (closed)).

Option 2 preserves the pre_get_sources workarounds:

What's the best way to test this MR?

What are the relevant issue numbers?

Edited by Guillaume Chauvel

Merge request reports