Draft: PoC: Option A - FF_GIT_URLS_WITHOUT_TOKENS + override credential helper for DAP

Andras Herczegrequested to merge
aherczeg/593467/poc-dap-git-auth-credential-helper into master

What does this MR do?

Proof of Concept for Option A from #593467: replace the current sed-based git remote set-url workaround with a Runner-aware credential helper override.

Related to issue #593467.

Approach

  1. Enable FF_GIT_URLS_WITHOUT_TOKENS=true as a job variable, so the Runner sets origin to a clean URL (no token embedded) and configures a credential.<host>.helper that returns CI_JOB_TOKEN instead of using insteadOf URL rewriting.
  2. Override credential.helper via two GIT_CONFIG_* env var entries:
    • credential.helper='' resets the helper stack (drops the Runner's CI_JOB_TOKEN helper).
    • An inline shell helper that echoes username=oauth / password=${GIT_PASSWORD} (the DAP OAuth token).
  3. Remove the sed-based git remote set-url from main_workflow_commands. It is no longer needed, and it was the source of the on-disk and process-listing token exposure documented in the issue.

Files changed

  • ee/app/services/ai/duo_workflows/start_workflow_service.rb
    • base_variables: add FF_GIT_URLS_WITHOUT_TOKENS: 'true'.
    • git_environment_variables: bump GIT_CONFIG_COUNT from 2 to 4; add the two credential.helper entries.
    • main_workflow_commands: remove the git remote set-url ... | sed line.

Why this addresses the issue

The current implementation (added in !226743 (merged)) writes the OAuth token to .git/config on disk and briefly exposes it in process listings via sed. The accepted-risk note in the issue lists exactly these as the concerns to eliminate.

With this PoC:

  • ✅ Token is never written to .git/config.
  • ✅ Token is never exposed in process listings.
  • ✅ origin stays as the clean URL (LLM-friendly, addresses Sebastian's concern in note 3187622813).
  • ✅ Same mechanism works transparently for LFS / fetch / push.
  • ✅ Aligns with the pattern already used in Remote Development Workspaces (workspace_variables_git_credential_store.sh).

Caveats / Open questions for evaluation

  1. GIT_CONFIG_NOSYSTEM=1 and GIT_CONFIG_GLOBAL=/dev/null are already set by DAP. We need to confirm that the Runner's get_sources stage (which is what consumes FF_GIT_URLS_WITHOUT_TOKENS) still works correctly with those env vars present. If the Runner relies on system/global git config to write its credential helper, we may need to revisit and instead override the helper inside main_workflow_commands (after the Runner's clone phase) rather than via env vars.
  2. Submodule authentication has been called out as a known issue with FF_GIT_URLS_WITHOUT_TOKENS (gitlab-org/gitlab-runner#38801). DAP workloads currently do not appear to depend on submodules during clone, but worth verifying.
  3. Runner version dependency: FF_GIT_URLS_WITHOUT_TOKENS exists today but is off by default. Self-managed customers on older Runner versions need to be considered before this can ship as a non-PoC.
  4. Spec updates are intentionally not included in this PoC. The existing specs in ee/spec/services/ai/duo_workflows/start_workflow_service_spec.rb (notably the git environment variables and setup_script configuration describe blocks) will need updating once the approach is validated.

Testing

Manual testing recommended:

  • Run a DAP workflow and inspect the workload container's .git/config: the OAuth token should no longer be present.
  • Verify git fetch / git push from the DAP container against origin still succeed.
  • Verify nothing in ps output exposes the token.

Checklist

  • Branch prefixed with aherczeg/593467/
  • Tests updated (deferred until approach is validated)
  • Manual verification on a real DAP run

/cc @bastirehm @stanhu @viktomas

Merge request reports