git 2.16, Jenkins git client plugin, and ""

git 2.16, Jenkins git client plugin, and ""

[Mark Waite]

It appears that git 2.16.0 and 2.16.1 have introduced a change which
surprises the Jenkins git client plugin.

Git 2.16.0 and 2.16.1 on Linux both report "fatal: ssh variant
'simple' does not support setting port" when used in the context of
the Jenkins git client plugin.

The solution we've accepted into the git client plugin source code is
to set the environment variable "GIT_SSH_VARIANT=ssh".  That allows
the failing case to pass, and does not seem to harm older versions of
git.

The documentation at https://git-scm.com/docs/git says that
GIT_SSH_VARIANT "overrides Git’s autodetection whether
GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer to OpenSSH, plink or
tortoiseplink."

I haven't seen the same message from Git 2.16.1 for Windows.

The Jenkins bug report
(https://issues.jenkins-ci.org/browse/JENKINS-49111) describes the
user experience.

Is the GIT_SSH_VARIANT solution expected to be used by git consumers
like the Jenkins git client plugin when passing credential information
through environment variables like SSH_ASKPASS?

I see "ssh", "plink", and "tortoiseplink" as values of GIT_SSH_VARIANT
used in tests, and "auto", "putty", and "simple" used in the source
code in addition to "ssh", "plink", and "tortoiseplink".  What are the
allowed values for GIT_SSH_VARIANT?

What is the recommended value so that the Jenkins git client plugin
can remain most compatible with previous behavior?

No value was assigned previously to GIT_SSH_VARIANT in the Jenkins git
client plugin.  I was expecting that git would choose "ssh" as the
default value for GIT_SSH_VARIANT, rather than apparently choosing
"simple".

Is this a bug, or is this the new, intentional behavior of git?

Thanks,
Mark Waite

Re: git 2.16, Jenkins git client plugin, and ""

[Bryan Turner]

On Wed, Jan 24, 2018 at 3:55 PM, Mark Waite <mwaite@cloudbees.com> wrote:
> It appears that git 2.16.0 and 2.16.1 have introduced a change which
> surprises the Jenkins git client plugin.
>
> Git 2.16.0 and 2.16.1 on Linux both report "fatal: ssh variant
> 'simple' does not support setting port" when used in the context of
> the Jenkins git client plugin.

We noticed a similar issue in Bitbucket Server's tests, related to us
using a wrapper script with the GIT_SSH variable. Some further
discussion is available in [1].

>
> The solution we've accepted into the git client plugin source code is
> to set the environment variable "GIT_SSH_VARIANT=ssh".  That allows
> the failing case to pass, and does not seem to harm older versions of
> git.
>
> The documentation at https://git-scm.com/docs/git says that
> GIT_SSH_VARIANT "overrides Git’s autodetection whether
> GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer to OpenSSH, plink or
> tortoiseplink."
>
> I haven't seen the same message from Git 2.16.1 for Windows.

Our Windows builds didn't seem to fail for this either, which was interesting.

>
> The Jenkins bug report
> (https://issues.jenkins-ci.org/browse/JENKINS-49111) describes the
> user experience.
>
> Is the GIT_SSH_VARIANT solution expected to be used by git consumers
> like the Jenkins git client plugin when passing credential information
> through environment variables like SSH_ASKPASS?

The expectation seems to be that if you use GIT_SSH or
GIT_SSH_COMMAND, you'll also use GIT_SSH_VARIANT to tell Git what to
expect, because it doesn't (shouldn't?) make assumptions, starting in
2.16, that your custom SSH uses OpenSSH syntax.

>
> I see "ssh", "plink", and "tortoiseplink" as values of GIT_SSH_VARIANT
> used in tests, and "auto", "putty", and "simple" used in the source
> code in addition to "ssh", "plink", and "tortoiseplink".  What are the
> allowed values for GIT_SSH_VARIANT?
>
> What is the recommended value so that the Jenkins git client plugin
> can remain most compatible with previous behavior?

"ssh" is probably the most compatible, because I'm pretty sure prior
to 2.16 that behavior was the assumed behavior.

>
> No value was assigned previously to GIT_SSH_VARIANT in the Jenkins git
> client plugin.  I was expecting that git would choose "ssh" as the
> default value for GIT_SSH_VARIANT, rather than apparently choosing
> "simple".
>
> Is this a bug, or is this the new, intentional behavior of git?

It's intentional. There was some discussion (again, see [1]) about
whether the change needed further changes, but it doesn't appear any
further changes were made.

>
> Thanks,
> Mark Waite

[1]: https://public-inbox.org/git/CAGyf7-FQp4q2vvH1ponQvmVDTu0hiMSK1JKytQZ4O1i0MCnz7g@mail.gmail.com/

Hope this helps!
Bryan

Re: git 2.16, Jenkins git client plugin, and ""

[Mark Waite]

On Wed, Jan 24, 2018 at 5:31 PM, Bryan Turner <bturner@atlassian.com> wrote:
> On Wed, Jan 24, 2018 at 3:55 PM, Mark Waite <mwaite@cloudbees.com> wrote:
>> It appears that git 2.16.0 and 2.16.1 have introduced a change which
>> surprises the Jenkins git client plugin.
>>
>> Git 2.16.0 and 2.16.1 on Linux both report "fatal: ssh variant
>> 'simple' does not support setting port" when used in the context of
>> the Jenkins git client plugin.
>
> We noticed a similar issue in Bitbucket Server's tests, related to us
> using a wrapper script with the GIT_SSH variable. Some further
> discussion is available in [1].

Thanks for the confirmation!

>> Is the GIT_SSH_VARIANT solution expected to be used by git consumers
>> like the Jenkins git client plugin when passing credential information
>> through environment variables like SSH_ASKPASS?
>
> The expectation seems to be that if you use GIT_SSH or
> GIT_SSH_COMMAND, you'll also use GIT_SSH_VARIANT to tell Git what to
> expect, because it doesn't (shouldn't?) make assumptions, starting in
> 2.16, that your custom SSH uses OpenSSH syntax.

That seems sensible.  There are other areas in the plugin which assume
OpenSSH syntax, so it is fair to make it explicit in the plugin.

We'll proceed with GIT_SSH_VARIANT=ssh.

>> Is this a bug, or is this the new, intentional behavior of git?
>
> It's intentional. There was some discussion (again, see [1]) about
> whether the change needed further changes, but it doesn't appear any
> further changes were made.

Thanks very much!

>>
>> Thanks,
>> Mark Waite
>
> [1]: https://public-inbox.org/git/CAGyf7-FQp4q2vvH1ponQvmVDTu0hiMSK1JKytQZ4O1i0MCnz7g@mail.gmail.com/
>
> Hope this helps!
> Bryan

-- 
Mark Waite