## Summary When `FF_USE_GIT_PROACTIVE_AUTH=true` (the default for GitLab.com runners), every clone with a Gitaly-advertised bundle URI fails the bundle URI download with the misleading warning: ``` error: insufficient capabilities warning: failed to download bundle from URI 'https://storage.googleapis.com/...' warning: failed to fetch advertised bundles ``` The clone falls back to normal smart HTTP and succeeds, so the regression is invisible in job output beyond the warning — but the bundle URI optimization is silently disabled for every job. With `FF_USE_GIT_BUNDLE_URIS=true` (also default), this affects every job whose Gitaly repo has a bundle. ## Root cause `shells/abstract.go` adds `http.proactiveAuth=basic` as an **unscoped** `-c` override on the outer `git` command: - Clone path: https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/shells/abstract.go#L936-938 - Init+fetch path: https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/shells/abstract.go#L873-875 ```go if build.IsFeatureFlagOn(featureflags.UseGitProactiveAuth) { cloneArgs = append(cloneArgs, "-c", "http.proactiveAuth=basic") } ``` `git -c key=value` propagates to children via `GIT_CONFIG_PARAMETERS`, so the config applies to *every* HTTP request the cloning process tree makes — including the helper that Git's `bundle-uri.c:download_https_uri_to_file()` spawns to fetch the signed `https://storage.googleapis.com/...` bundle URL. The bundle URL is a GCS V4 signed URL that needs no credentials, but with proactive-auth on, Git asks the credential helper first. The runner also sets `credential.interactive=never` (`shells/abstract.go` around line 999), so the helper can't prompt and Git dies with `unable to get password from user` *before* issuing any HTTP request. The parent in `bundle-uri.c` sees EOF on the helper's stdout, never receives the `get` capability, and surfaces the generic "insufficient capabilities" error. ## Evidence (`GIT_TRACE2_EVENT`) From an actual failing job (relevant events only, paraphrased): ``` child_start argv=["git-remote-https","https://storage.googleapis.com/.../default.bundle?Expires=...&Signature=..."] def_repo worktree=/ cmd_name remote-curl hierarchy=clone/remote-curl data credential interactive/skipped=1 error "unable to get password from user" (usage.c:73) exit code=128 t_abs=0.001371 error "insufficient capabilities" (parent) (usage.c:92) child_exit code=128 t_rel=0.003957 ``` 3.9 ms from spawn to exit — no network I/O happened. The credential lookup is what kills the helper. ## Reproduction Any pipeline on a GitLab instance where Gitaly advertises a bundle URI, with default runner feature flags. The warning appears at the top of every "Getting source from Git repository" stage. ## Workaround There is **no job-level workaround** on runners that pin the feature flag in `config.toml` (e.g. GitLab.com SaaS runners). Runner-side feature flags set via `environment = ["FF_USE_GIT_PROACTIVE_AUTH=true"]` (or the dedicated `feature_flags` block) take precedence over `.gitlab-ci.yml` `variables:`, so overriding the flag in CI yaml is a no-op. Available options for affected users: - **Self-hosted runner**: flip `FF_USE_GIT_PROACTIVE_AUTH=false` in the runner's `config.toml` (and reload the runner). This stops the unscoped `-c http.proactiveAuth=basic` from being added, the bundle-URI helper no longer does the pre-emptive credential lookup, and bundle URIs work again. - **SaaS runner**: no user-facing workaround. The fix has to land in the runner itself. ## Proposed fix Scope the proactive-auth config to the host the runner is cloning from instead of leaving it global. The runner already has a helper for this: `getRemoteHost(build)` at `shells/abstract.go:630` returns scheme+host+port of `build.GetRemoteURL()`, which honors `clone_url` when set. **Option A** — scope the `-c`: ```go if build.IsFeatureFlagOn(featureflags.UseGitProactiveAuth) { remoteHost, err := b.getRemoteHost(build) if err != nil { return err } cloneArgs = append(cloneArgs, "-c", fmt.Sprintf("http.%s.proactiveAuth=basic", remoteHost)) } ``` (applied in both `writeCloneRevisionCmd` and `writeRefspecFetchCmd`) `http.proactiveAuth` is wired through Git's standard urlmatch machinery (`http.c:1327-1342`), so URL-scoped entries work the same way as for any other `http.*` key — the runner already uses this pattern for `http.<remoteHost>.sslCAInfo` and `credential.<remoteHost>.helper`. The resulting config: ``` http.https://us-east1.ci-gateway.int.gprd.gitlab.net:8989.proactiveAuth=basic ``` is applied by Git's urlmatch only to requests whose URL has that prefix (the clone itself, the packfile fetch, etc.), and **not** to the bundle URI request to `storage.googleapis.com`, so the bundle-URI helper no longer hits the credential machinery. **Option B** — move proactive-auth into the URL-scoped section of `extConfigFile` alongside the existing `insteadOf` entries, so it's never serialized as an unscoped global `-c`. Same end result, different implementation surface. ## Impact - Silent: most users won't notice; the clone succeeds via fallback. - Cost: bundle URI optimization is defeated for every affected clone — bigger Gitaly load, slower clones, no benefit from the feature being shipped on by default. - Affects all runners with `FF_USE_GIT_PROACTIVE_AUTH=true` (default) cloning from Gitaly instances that advertise bundle URIs. On runners that pin the flag in `config.toml` (including GitLab.com SaaS), affected users have no way to opt out themselves. ## Environment - gitlab-runner: 19.0.0~pre.1138.ga0a1e0e8 - Git in helper image: 2.52.0 (alpine prebuilt helper image) - Affected feature flags (both default-on): `FF_USE_GIT_PROACTIVE_AUTH`, `FF_USE_GIT_BUNDLE_URIS`