Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 8, 2018, 13:04 UTC
Message-ID: <nycvar.QRO.7.76.6.1811081356350.39@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqr2fwa0ew.fsf@gitster-ct.c.googlers.com>

Hi,

On Thu, 8 Nov 2018, Junio C Hamano wrote:

> I am tempted to say "//<token>/<the remainder>" might also be such a
> way, even in the POSIX world, but am not brave enough to do so, as I
> suspect that may have a fallout in the Windows world X-<.

It does. //server/share is the way we refer to UNC paths (AKA network drives).

> An earlier suggestion by Duy in [*1*] to pretend as if we take
> $VARIABLE and define special variables might be a better direction.

My only qualm with this is that `$VARIABLE` is a perfectly allowed part of a path. That is, you *could* create a directory called `$VARIABLE` and reference that, and then the expand_user_path() function (or whatever name we will give it) would always expand this, with no way to switch it off.

Granted, this is a highly unlikely scenario, but I would feel a bit more comfortable with something like

	<RUNTIME_PREFIX>/ssl/certs/ca-bundle.crt

Of course, `<RUNTIME_PREFIX>` is *also* a perfectly valid directory name, but I would argue that it is even less likely to exist than `$RUNTIME_PREFIX` because the user would have to escape *two* characters rather than one.

> Are there security implications if we started allowing references to
> environment varibables in strings we pass expand_user_path()?

Probably. But then, the runtime prefix is not even available as environment variable...

Ciao, Dscho

Show 11 quoted lines

> If we cannot convince ourselves that it is safe to allow access to any
> and all environment variables, then we probably can start by specific
> "pseudo variables" under our control, like GIT_EXEC_PATH and
> GIT_INSTALL_ROOT, that do not even have to be tied to environment
> variables, perhaps with further restriction to allow it only at the
> beginning of the string, or something like that, if necessary.
> 
> [References]
> 
> *1* <CACsJy8DmyU_Kn4yytu_PQdpppXO8wLcuuzQ-fjwnyjA0ntB2Dw@mail.gmail.com>
>