Duo Workflow git hardening (`GIT_CONFIG_GLOBAL=/dev/null`) breaks `get_sources` for self-managed instances with custom CAs
#### Summary Since 18.11 ([MR !226743](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/226743)), Duo Workflow workload jobs inject `GIT_CONFIG_GLOBAL=/dev/null` to sandbox the agent. This causes the runner's `git config --global http.<host>.sslCAInfo` write during `get_sources` to silently go to `/dev/null`, so git clone fails with OpenSSL error 20 on any self-managed instance using custom or self-signed CAs. Worked in 18.9. Broke in 18.11. Normal CI/CD jobs are unaffected — only Duo Workflow workload pipelines hit this. #### Workaround Set `GIT_SSL_CAINFO` in the runner's `config.toml` (bypasses git config files entirely). CI/CD variables won't work — the workload variable gate [filters them out](https://docs.gitlab.com/user/duo_agent_platform/flows/execution_variables/#custom-cicd-variables). ```toml [[runners]] environment = ["GIT_SSL_CAINFO=/etc/gitlab-runner/certs/ca.crt"] [runners.docker] volumes = ["/path/to/ca-bundle.crt:/etc/gitlab-runner/certs/ca.crt:ro"] ``` #### Fix directions 1. Forward `CI_SERVER_TLS_CA_FILE` as `GIT_SSL_CAINFO` in the workload variables — keeps the `/dev/null` hardening intact. 2. Replace `/dev/null` with a writable temp file so the runner's `sslCAInfo` write lands somewhere real. 3. Add `sslCAInfo` to the existing `GIT_CONFIG_COUNT`/`GIT_CONFIG_KEY_N`/`GIT_CONFIG_VALUE_N` mechanism already used for `safe.directory`. #### References - [MR !226743](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/226743) — introduced the hardening (18.11) - [Issue #596610](https://gitlab.com/gitlab-org/gitlab/-/issues/596610) — related Node.js CA issue in the Duo image - Support case [714465](https://gitlab.zendesk.com/agent/tickets/714465) (internal)
issue