I believe the 401 error code in the stack trace indicates that the request was not authorized by the web server. The git-client-plugin 1.6.4 switched from an obsolete version of an http library to a newer supported version of that http library. It also added support the NTLM credentials and for Team Foundation Server git repositories.

If you'd be willing to perform the test, I'd appreciate having you attempt to upgrade just the git-client-plugin, without upgrading git-plugin. If it fails then that will point to changes in git-client-plugin as the most likely cause. If it passes, then it will need to be investigated in both.

Does the https server use a self-signed certificate?

yes, with only git-client upgraded to 1.6.4, git fetch failed.

The server is not using self-signed cert.

yes, with only git-client upgraded to 1.6.4, git fetch failed.

The server is not using self-signed cert.

Thanks. That indicates the problem is likely in the git-client-plugin changes from 1.6.3 to 1.6.4. We'll need you to do deeper investigation to try to narrow the failure modes. Some of the questions which may help narrow the failure modes include:

• Does the problem also appear on a copy of the failing job?
• Does the problem also appear on a newly created job using the same git URL and credentials?
• Does the problem also appear with other https git repositories in your environment?
• Does the problem also appear for you with https git repositories outside your environment? (like github or bitbucket)
• Is there a public URL which can be used to see the same problem?

I can add a bit of information.

Rolling back to 1.6.3 solves the problem.

I get the error pulling from bitbucket, and it fails for every repo I pull from bitbucket.

Thanks for the hint to use bitbucket.

I can see the failure if I configure a credential with a username and password for a private bitbucket git repository. If the bitbucket repository is public (which I had been using before), then the clone succeeds. More exploration will be required.

I don't see the same failure if I configure a credential with a username and password for a private github repository. Public github repositories also do not show any issue.

Posting a link to my earlier (wire) analysis on this (the bug is not directly related, but for me is dependent on getting this issue fixed): JENKINS-20939 12/Mar/14 3:44 AM

It appears that the authentication handshaking has changed since the earlier HTTP library

I finally had some time to dig into this.

What caused the problem for me was that when you copy the https address from a private repository on bitbucket it is displayed as:

https://username@bitbucket.org/username/repo.git

and for a public repo it is:

https://bitbucket.org/username/repo.git

Removing the `username@` from the url in the jenkins setup, fixes the problem for private repos.

A fix that would allow either format would be to strip the username@ from the url in the `checkCredentials()`: https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1854

e.g something like this:

diff --git a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java b/src/main/java/org/jenkins
index 9fd48ab..feb95d2 100644
--- a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
+++ b/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
@@ -1843,6 +1843,7 @@ public class CliGitAPIImpl extends LegacyCompatibleGitAPIImpl {
      */
     private void checkCredentials(URIish u, StandardCredentials cred) {
         String url = u.toPrivateString();
+        url = url.replaceAll("[\\w]+@", "");
         final HttpClientBuilder clientBuilder = HttpClients.custom();
         final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
         clientBuilder.setDefaultCredentialsProvider(credentialsProvider);