Re: GIT_ASKPASS absolute path detection bug on Windows

From: "Torsten Bögershausen" <tboegi@web.de>
To: "András Kucsma" <andras.kucsma@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: GIT_ASKPASS absolute path detection bug on Windows
Date: Sun, 22 Mar 2020 08:31:05 +0100	[thread overview]
Message-ID: <20200322073105.zh2tqycu2fgydf3e@tb-raspi4> (raw)
In-Reply-To: <CANPdQv+tCnfy_csM8EwuqAYBtgkJ3RhRvo+ALbzO=BcZA7qJtg@mail.gmail.com>

On Sat, Mar 21, 2020 at 12:42:50PM +0100, András Kucsma wrote:
> Hi All,
>
> I believe to have found an issue regarding properly executing the
> GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0
> installed using cygwin.
>
> ## To reproduce:
>
> Assume you have the askpass binary at C:\askpass.bat. In CMD the
> following commands reproduce the issue:
>
> C:\> set GIT_ASKPASS=C:\askpass.bat
> C:\> git clone https://<private_repository>.git
> Cloning into '<private_repository>'...
> error: cannot run C:\askpass.bat: No such file or directory
> [... proceeds to interactively ask for username and password ...]
>
> On the other hand, if we change the GIT_ASKPASS environment variable
> slightly, so that there is a forward slash (/) instead of a backslash
> (\), things work as expected:
>
> C:\> set GIT_ASKPASS=C:/askpass.bat
> C:\> git clone https://<private_repository>.git
> Cloning into '<private_repository>'...
> [... success ...]
>
> ## Some context:
>
> The source of the problem, is that if git doesn't find a forward slash
> anywhere in the path, it assumes it is not a real path and has to look
> for the binary using the PATH environment variable. See in
> prepare_cmd():
> https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439
>
> You can see that the "cannot run" error message is printed here, just
> after prepare_cmd() returned -1:
> https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753
>
> I believe this was introduced in late 2018 around git v2.19.2,
> although I did not actually bisect the issue:
> https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415
>
>
> I hope I'm sharing this bug at the right forum. Please direct me to
> the proper place if not.

Yes, you came to the rigth place.
Thanks for the report and the detailed analysis.

A quick fix, and a begin of a patch, could be to use
has_dos_drive_prefix() which will look for C: and will therefore even work
with C:\

	/*
	 * If there are no '/' characters in the command then perform a path
	 * lookup and use the resolved path as the command to exec.  If there
	 * are '/' characters, we have exec attempt to invoke the command
	 * directly.
	 */
	if ((!strchr(out->argv[1], '/')) ||
	    (has_dos_drive_prefix(out->argv[1]))) {
		char *program = locate_in_PATH(out->argv[1]);
[]

If you want to play around with the code a little bit, and send us a "git diff",
we can convert that into a patch.

Wellcome to the Git community.

>
> Thank you,
> Andras