Update: This issue is only deprecating `FF_RESOLVE_FULL_TLS_CHAIN`. https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39812 is a follow-up issue to remove it. --- Part of https://gitlab.com/groups/gitlab-org/-/work_items/23127 (assigned in [note_3666997909](https://gitlab.com/groups/gitlab-org/-/work_items/23127#note_3666997909)). - **Flag** and current category: [`FF_RESOLVE_FULL_TLS_CHAIN`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/helpers/featureflags/flags.go#L24) (definition at [`flags.go#L215`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/helpers/featureflags/flags.go#L215)), categorized in the epic as `Legacy switch-backs — the default is already right (19)`. Default `false`, `ToBeRemovedWith` empty. - **Introduced by**: https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3699+s by [Stan Hu](https://gitlab.com/stanhu), merged 2022-11-07, released in v15.6.0 with default `true`. Motivation: `#29373` (macOS rejects SHA-1 signed roots, so `Certificate.Verify` fails and `CI_SERVER_TLS_CA_FILE` cannot be generated). The flag was added as an escape hatch to *disable* chain resolution. - **Flip history**: one flip, no reverts. https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/4292+s by Stan Hu set the default to `false` in %16.4 (merged 2023-09-21), closing https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/36319. Rationale: libcurl v7.68 (Jan 2020) trusts a CA that is not self-signed, so resolving down to the self-signed root is no longer required. The default has been `false` for 2.9 years. - **Open issues** referencing the flag: none. All known references are closed: https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/36319 (%16.4), https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/29373 (%15.5), https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/36318 (related motivation, PKCS7 library). - **Author contacted?**: not yet. The original author is still active on GitLab.com; will ask whether anything still depends on the `true` path before proposing removal. - **Verdict**: to be recorded here. See *Evidence gathered so far* and *Open question* below. - **Action**: pending the verdict. ### Evidence gathered so far **Production references, all through the `featureflags` package** (no `env:` struct tag consumer, checked with a literal `FF_RESOLVE_FULL_TLS_CHAIN` grep, so the caveat below does not apply to this flag): | Location | Role | |---|---| | [`network/gitlab.go#L703`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/gitlab.go#L703) | `RequestJob`, on `201 Created` | | [`network/gitlab.go#L1038`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/gitlab.go#L1038) | job router discovery, on `200 OK` | | [`network/client.go#L485`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/client.go#L485), [`#L501`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/client.go#L501), [`#L510`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/client.go#L510) | plumbs `resolveFullChain` into `ca_chain.NewBuilder` | | [`helpers/tls/ca_chain/builder.go#L79`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/helpers/tls/ca_chain/builder.go#L79) | the actual branch: `if b.resolveFullChain { ... b.resolver.Resolve(...) }` | **It is config-only by construction.** Both call sites read the flag from `RunnerSettings` (`config.IsFeatureFlagOn`) while polling for a job or discovering the job router, i.e. before any job exists. There is no job context to read a CI/CD variable from, so `FF_RESOLVE_FULL_TLS_CHAIN` can only be set under `[runners.feature_flags]`. This matches the *"can be set in the job variables"* column of the generated docs table, and it means the usual "users can override it per job" argument does not apply here. **Removal is not a one-line delete.** With the default already `false`, deleting the flag makes the entire resolver half of `helpers/tls/ca_chain` unreachable: `resolver.go`, `resolver_chain.go`, `resolver_url.go`, `resolver_verify.go` and `helpers.go` (about 380 lines), the generated mocks in `mocks.go` (about 310 lines), and their tests (about 630 lines). That is roughly 1,300 of the package's 1,719 lines. Only [`network/client.go#L510`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/network/client.go#L510) constructs the builder, so nothing outside this path keeps them alive. ### Open question for the verdict The switch-back exists for environments where Git is linked against libcurl older than v7.68 and needs the self-signed root present in `CI_SERVER_TLS_CA_FILE`. That is a property of the user's environment, not a rollout that finished, which is the epic's own definition of *permanent configuration*. So the choice is: 1. **Remove**, if there is no remaining evidence of users on pre-2020 libcurl with a self-signed root, which also buys the `ca_chain` cleanup above. 2. **Elevate to `config.toml`**, if such users do exist, keeping the `FF_` form as a deprecated alias. Evidence I plan to collect: the original author's recollection, support tickets or issues since %16.4 asking to set the flag back to `true`, and whether any distro still ships libcurl < 7.68 in a supported runner target. ### Documentation fix needed regardless of the verdict [`docs/install/osx.md#L316`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/docs/install/osx.md#L316) still instructs users to set `FF_RESOLVE_FULL_TLS_CHAIN = false` as a workaround for the v15.5.0 `couldn't build CA Chain` error. That has been the default since %16.4, so the advice is a no-op for every currently supported version. [`docs/configuration/tls-self-signed.md#L320`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/docs/configuration/tls-self-signed.md#L320) carries the same pre-16.4 phrasing (*"you might also have to disable"*). Both should be reworded or scoped to 16.3 and earlier. > ⚠️ **Removal caveat.** Not every flag is read through the `featureflags` package. `FF_USE_DIRECT_DOWNLOAD` is consumed via a struct tag (`env:"FF_USE_DIRECT_DOWNLOAD"` at [`commands/helpers/artifacts_downloader.go:28`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/commands/helpers/artifacts_downloader.go#L28)), so the `featureflags.UseDirectDownload` constant has **no production references at all**. A removal MR that greps for the Go identifier will conclude the flag is dead code and silently break direct download. Every removal must grep for the literal `FF_` string. > 📝 **Editing this epic's table.** The inventory is generated from [`helpers/featureflags/flags.go`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/helpers/featureflags/flags.go) plus the GitLab API. GitLab descriptions are last-write-wins with no merge, so two people editing the table in the same window will silently clobber each other. Keep table edits to the single row you own, and treat your issue, not this description, as the authoritative record of your verdict.