jenkinsci/git-client-plugin — pull request #116 by olivierdagenais (2014-02-21 20:12:42+00:00)
Title: [JENKINS-21401] Add support for NTLM authentication, such as TFS 2013 Git servers

Overview
======
Microsoft's Team Foundation Server 2013 supports a Git server hosted on IIS, usually configured with "Windows authentication" for a single-sign on experience in an organization's intranet. Unfortunately, that makes it slightly non-standard as a Git server, hence [JENKINS-20401](https://issues.jenkins-ci.org/browse/JENKINS-21401).

This pull request adds support for [optional] NTLM authentication, making the Jenkins Git-Client plugin "just work" with TFS 2013 Git servers. To make this happen, I had to upgrade to Apache HttpComponents (from the unsupported Apache Commons HttpClient 3.x) and also switch to the new classes (i.e. `org.apache.http.*`).

Manual Testing
==========
There is a small element of risk involved since the new HttpComponents API didn't map 1-to-1 with the old one, so I performed more testing as a result. I deployed the `git-client.hpi` I built into a test Jenkins instance (running on Windows Server), which has one Linux (CentOS 6.2) agent.
1. Created a job with a Git repository using TFS 2013 Git (with a server we have on our LAN) and confirmed that:
* 1.1 Providing Credentials in the configuration page got the "Failed to connect ... (status = 401)" error message to go away.
* 1.2 The job was able to clone and fetch when running on the (Windows) master.
* 1.3 The job was able to clone and fetch when running on the (Linux) slave.
* 1.4 The job was able to poll.
2. Created a job with a Git repository using a Git server that did not require authentication (GitHub) and repeated tests 1.2, 1.3 and 1.4.
3. Created a job with a Git repository using a Git server through a proxy that did not require authentication (I used Squid 3.1) and repeated tests 1.2, 1.3 and 1.4.
4. Created a job with a Git repository using a Git server through a proxy that required authentication (Squid 3.1 with Basic auth) and repeated tests 1.2, 1.3 and 1.4.
5. Created a job with a Git repository using a Git server that used a self-signed certificate with org.jenkinsci.plugins.gitclient.GitClient.untrustedSSL undefined (defaults to false) and repeated tests 1.2, 1.3 and 1.4. 1.2 and 1.3 would fail, as expected, with "sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" while 1.4 always reported a change, which triggered a build on every check (not sure if this is the right behaviour, but I didn't touch that part of the code, so presumably it worked like that before).
6. Created a job with a Git repository using a Git server that used a self-signed certificate with org.jenkinsci.plugins.gitclient.GitClient.untrustedSSL set to true and repeated tests 1.2, 1.3 and 1.4.
* 6.1 Test 1.2 was able to check the credentials against the remote (since that part is using Apache HttpComponentns) but would fail the build when it called `git fetch (...)` because git.exe performs its own certificate check.
* 6.2 Test 1.3 failed until I also added "-Dorg.jenkinsci.plugins.gitclient.GitClient.untrustedSSL=true" in the node's "JVM Options", then reconnected the slave, because it appears the CliGitAPIImpl code executes directly on the slave's JVM. After doing all that, I got the same behaviour as 6.1: `git fetch` failed due to an invalid certificate.
* 6.3 Test 1.4 reported a change, probably because none of the builds were able to fetch a repo to have a changeset to compare with.