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