Git cannot read password after upgrading git client plugin from 1.19.6 to 2.1.0

133 views
Skip to first unread message

shaneoh1980 McP

unread,
Jan 6, 2017, 2:16:20 AM1/6/17
to Jenkins Users
I'm trying to upgrade our Jenkins to 2, but coming accross a problem with git authentication. I've got Git credentials loaded and they currently work, but when I upgrade the plugin from 1.19.6 to 2.1.0, all jobs that use Git for SCM fail with the same error message.  As soon as I downgrade the plugin, they work again. I've searched everywhere I can for an answer but don't seem to be able to find anything.

Where the jobs succeed the output suggests that .gitcredentials is being used to authenitcate, but with the new plugin GIT_ASKPASS is being used. Not sure if this is related but I suspect it is. There's a full explanation here:


But the relevant output is this:

08:18:40  > C:\Program Files\Git\cmd\git.exe init C:\Program Files (x86)\Jenkins\workspace\project # timeout=10
08:18:40 Fetching upstream changes from https://github.com/mycompany/myrepo.git
08:18:40  > C:\Program Files\Git\cmd\git.exe --version # timeout=10
08:18:40 using GIT_ASKPASS to set credentials
08:18:40  > C:\Program Files\Git\cmd\git.exe fetch --tags --progress https://github.com/mycompany/myrepo.git +refs/heads/*:refs/remotes/origin/*
08:18:41 ERROR: Error cloning remote repo 'origin'
08:18:41 hudson.plugins.git.GitException: Command "C:\Program Files\Git\cmd\git.exe fetch --tags --progress https://github.com/mycompany/myrepo.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
08:18:41 stdout:
08:18:41 stderr: '*dds23' is not recognized as an internal or external command,
08:18:41 operable program or batch file.
08:18:41 error: unable to read askpass response from 'C:\Windows\TEMP\pass6274847349411211542.bat'
08:18:41 bash: /dev/tty: No such device or address
08:18:41 error: failed to execute prompt script (exit code 1)
08:18:41 fatal: could not read Password for 'https://us...@github.com': No error

Has anyone else come across this issue?

Mark Waite

unread,
Jan 6, 2017, 5:12:51 AM1/6/17
to Jenkins Users

You can't change the Jenkins git client plugin from using ASKPASS to using .gitcredentials. The plugin does not have selectable password prompting methods.

It used .gitcredentials in releases prior to 2.0, and switched to ASKPASS in releases 2.0 and later. That change was made so that submodule authentication could be added in git client plugin 2.0.

There are open bug reports which describe scenarios where Windows based username / password setups no longer work with https based access to a git repository. Some of those scenarios include:

Some temporary alternatives prior to the fixes for those open bugs include:

  • Stay with your current versions (git client plugin 1.19.6 and git plugin 2.x) - upgrade Jenkins but don't upgrade the git client plugin and the git plugin
  • Manually upgrade to the latest git client plugin 1.x and latest git plugin 2.x by downloading and installing git client plugin 1.21.0 and git plugin 2.6.1 so that you can stay with git client plugin prior to the credentials change. You'd need to download those files, then use the Jenkins plugin manager "Advanced" tab to upload those newer (but not newest) versions of the git client plugin and git plugin
  • Upgrade to latest git client and git plugin, and change your Git URL's from using username / password (https) authentication to using private key (ssh / scp) credentials, store those private keys as Jenkins credentials, and update the jobs to use those private key credentials rather than username / password credentials
  • Change your git account passwords to not use characters which require escaping through the Windows command prompt
  • Assist with evaluation of the pending git client plugin pull request which adjusts the Windows escaping of passwords in the plugin. The pull request is PR231 on github
My apologies for those bugs.  The year of beta testing before release of git client plugin 2.0 was not enough to detect those problems.

Thanks,
Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8868d01f-c2d0-4675-a265-cf2873dce009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Waite

unread,
Jan 6, 2017, 5:19:52 AM1/6/17
to Jenkins Users
If you choose to help evaluate the pull request, you can download the latest build from my evaluation branch at https://drive.google.com/open?id=0B9GyYWyfT1N5Y1NPS1hnbU13elk .  That is an unreleased build of the git client plugin which includes the Windows password escaping change.

Mark Waite

Mark Waite

unread,
Jan 6, 2017, 5:40:22 AM1/6/17
to Jenkins Users
There is one other alternative (referenced in the serverfault posting from "bobs"), though I don't recommend it.  If your Jenkins server is purely Windows based, and never has any agents ("slaves"), then you might be able to configure the git credentials manager on Windows to always answer the username / password prompts with your chosen password.  I don't recommend that solution because it requires that you perform that same configuration on every agent, and requires that you only use Windows machines as your agents.

I say "might be able to configure" because I believe it is theoretically possible to do that.  The user "bobs" on serverfault says that he has done it, so I think it is possible.  I've never done it.

Mark Waite


On Friday, January 6, 2017 at 3:19:52 AM UTC-7, Mark Waite wrote:
If you choose to help evaluate the pull request, you can download the latest build from my evaluation branch at https://drive.google.com/open?id=0B9GyYWyfT1N5Y1NPS1hnbU13elk .  That is an unreleased build of the git client plugin which includes the Windows password escaping change.

Mark Waite

On Fri, Jan 6, 2017 at 3:11 AM Mark Waite wrote:

You can't change the Jenkins git client plugin from using ASKPASS to using .gitcredentials. The plugin does not have selectable password prompting methods.

It used .gitcredentials in releases prior to 2.0, and switched to ASKPASS in releases 2.0 and later. That change was made so that submodule authentication could be added in git client plugin 2.0.

There are open bug reports which describe scenarios where Windows based username / password setups no longer work with https based access to a git repository. Some of those scenarios include:

Some temporary alternatives prior to the fixes for those open bugs include:

  • Stay with your current versions (git client plugin 1.19.6 and git plugin 2.x) - upgrade Jenkins but don't upgrade the git client plugin and the git plugin
  • Manually upgrade to the latest git client plugin 1.x and latest git plugin 2.x by downloading and installing git client plugin 1.21.0 and git plugin 2.6.1 so that you can stay with git client plugin prior to the credentials change. You'd need to download those files, then use the Jenkins plugin manager "Advanced" tab to upload those newer (but not newest) versions of the git client plugin and git plugin
  • Upgrade to latest git client and git plugin, and change your Git URL's from using username / password (https) authentication to using private key (ssh / scp) credentials, store those private keys as Jenkins credentials, and update the jobs to use those private key credentials rather than username / password credentials
  • Change your git account passwords to not use characters which require escaping through the Windows command prompt
  • Assist with evaluation of the pending git client plugin pull request which adjusts the Windows escaping of passwords in the plugin. The pull request is PR231 on github
My apologies for those bugs.  The year of beta testing before release of git client plugin 2.0 was not enough to detect those problems.

Thanks,
Mark Waite

shaneoh1980 McP

unread,
Jan 6, 2017, 6:08:09 AM1/6/17
to Jenkins Users
Hi Mark,

Thanks a lot for the detailed responses.  After banging my head against a brick wall for so long, I'm actually just happy to have the correct answer - and it is correct. I changed the password for our user to something not using those types of characters, and now the authentication is fine. 

We run slaves on various Linux distros so the last option isn't going to work for us but really, changing the password as a workaround is not onerous and you can still have a very strong one, so that's a great outcome for me.

Thanks again.
Reply all
Reply to author
Forward
0 new messages