Re: GIT_ASKPASS absolute path detection bug on Windows

["András Kucsma" <andras.kucsma@gmail.com>]

Thanks Torsten!
I submitted it as https://github.com/gitgitgadget/git/pull/587
I believe someone has to /allow me to be able to submit it.


On Mon, Mar 23, 2020 at 5:58 PM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Sun, Mar 22, 2020 at 12:44:33PM +0100, András Kucsma wrote:
> > On Sun, Mar 22, 2020 at 8:31 AM Torsten Bögershausen <tboegi@web.de> wrote:
> > >
> > > 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
> >
> > Thanks Torsten!
> >
> > I believe it is not enough to test only for the drive specifier, as
> > GIT_ASKPASS has to work with relative paths as well:
> > C:\SomeDirectory> set GIT_ASKPASS=.\SomeOtherDirectory\askpass.bat
> > C:\SomeDirectory> git clone https://<some_private_repository>.git
> >
> > My proposal patch is to take advantage of find_last_dir_sep function's
> > OS specific directory separator knowledge.
> > I posted the diff below, which is also available on github here:
> > https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
> >
> > diff --git a/run-command.c b/run-command.c
> > index f5e1149f9b..9fcc12ebf9 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
> > const struct child_process *cmd)
> >      }
> >
> >      /*
> > -     * 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 there are no dir separator characters in the command then perform
> > +     * a path lookup and use the resolved path as the command to exec. If
> > +     * there are dir separator characters, we have exec attempt to invoke
> > +     * the command directly.
> >       */
> > -    if (!strchr(out->argv[1], '/')) {
> > +    if (find_last_dir_sep(out->argv[1]) == NULL) {
> >          char *program = locate_in_PATH(out->argv[1]);
> >          if (program) {
> >              free((char *)out->argv[1]);
>
> András,
> The patch looks good to me.
> If you want, you can submit it here to the list,
> either with git send-mail
>
> or may be
>
> https://gitgitgadget.github.io/
>
> And please don't forget to sign-off the patch