Command-Line Git vs JGit in Jenkins Git Plugin — Divergent Certificate Validation Behavior

Integration Boundary: Command-Line Git and JGit

The Jenkins Git Plugin supports two Git implementations: command-line git (delegating to the OS trust store and git config http.sslCAInfo) and JGit (using the Java cacerts store and JSSE system properties). A single pipeline may invoke both — checkout via JGit while submodule or LFS operations fall back to command-line git — causing inconsistent certificate validation results against the same Git server.

No unified configuration point exists to synchronize trust decisions across both stacks. The Git Client Plugin's "Skip SSL verification" option only affects command-line git; JGit ignores it and requires Java-level trust store manipulation, which broadens the attack surface to all JVM network clients. Corporate MITM proxies and self-signed internal Git servers exacerbate the split, as the Plugin Manager (updates.jenkins.io) also depends exclusively on the Java trust store.

Maintainers have not converged on whether to introduce a unified SSL verification mode or deprecate one implementation since JGit integration arrived in 2016.

Open Questions

1. What configuration approach ensures both command-line git and JGit validate against the same CA bundle without global JVM or OS side effects?
2. Can submodule and LFS operations be forced to use the same Git implementation as the parent checkout?
3. Is there a roadmap for a unified SSL verification mode in the Git Plugin, or should teams standardize on one implementation?